Галоўная / Артыкулы / Палітра RAG для падчыннай політыкі кадроў з LangChain і LangGraph

Палітра RAG для падчыннай політыкі кадроў з LangChain і LangGraph

Прыем даных, MMR, перапісваўка з урахоўваннем історыі, адпаведныя на адповедзі, правілы карантэна, ацэнка, цітаты і оркестрацыя графаў для падрабніка з правілаў кадровай справы.

1510 слоў

Паспорт, які раскрывае процес прыему даных, адгутаванне MMR, запиты, які урахоўваюць історыю, перакананні ў безпецы, хукі для ацэнкі і UX для чату з калькама роўнаў.

Введэнне

Для аддзела кадраў у большых компаніях недастатнька проста генераваная адпаведзь. Памочны прыстрой для правіл не павінен выдумваць правіла выпачкі на адвароте пад час прадзейнавання. Ён должен адгутаваць затверджаныя дакументы і падкрэпляць кожны тверджэння цімі джэрамі. Гэта і є задача методу генеравання з адгутаваннем даных (RAG).

Модульная система запитанняў і адказоў па правілам пра кадры у стыле прымення можа аб’еднаваць Python, LangChain, LangGraph, чат-модель сумесную з OpenAI, ChromaDB, Streamlit, эмбеддінгі, методы адзыскання дадзэнняў MMR, перапісва запитоў з урахаваннем історыі, проектаванне запрошэнняў, модерацыю вхідных дадзэнняў, перакантрольванне вставкі запрошэнняў, ацэнку адзыскання дадзэнняў, памяць для канверсацый, стварэнне падсумкаў і экспорт у формат PDF. Мета — не дэмаверсія чат-бота, а система RAG, якая серьёзна ставіцца да якосці адзыскання дадзэнняў, контексту канверсацій, безпекі, ацэнкі і зручнасці выкарыстоўвання.

1. Проблема

Калі хтось запытае: «Сколькі дзён відпачыку з прычыны хворобы дазволены?», звычны LLM можа выдумаць адказ. У свою чаргу, асистент з пытанняў пра кадры должен:

  1. Зрозумець запыт
  2. Пашукаць дакументы організацыі, прынятныя для кадровай справы
  3. Адзыскаць найболей релевантныя часткі
  4. Перадаць гэтыя часткі моделі
  5. Стварыць адказ, базаваны на іх
  • Наводзіце джэрела, каб працаваючый могаў іх пераканаць.
  • Алгорытм работы: дакументы кадровага аддзелу → ўваходжэнне → разбіўка на часткі + метаданы → вектарныя представленні → ChromaDB → прыстрой для пошуку → запит, які урахоўвае історыю → адпаведныя дакументы → запрос, ўзгадваючы паводкі, → адпаведная адпаведь → цітаты.

    2. Уваходжэнне дакументаў

    Сырыя правілы ператвараюцца на часткі, якія можна шукать. Полныя дакументы занадта великія, ўсё жа ўскладнюючы включэнне іх у кожны запрос, і могу перапыліць ліміты контэкста. Часткі маюць метаданы, такія як назва файла, шлях, папка, тип дакумента і меткі джэрела — гэта стварае можлівасць пазней выкарыстоўваць іх для цітатаў, адлагоджэння проблем і аналізу результаатаў пошуку.

    3. Вектарныя представленні і храненне вектараў

    Кожная частка становіць вектарныя представленні:

    "Employees receive annual leave..."
                 ↓
           Embedding Model
                 ↓
          [0.12, -0.43, 0.87, ...]
    

    Вектары і метаданы зберагаюцца ў ChromaDB. Запыты корыстніка таксама ператвараюцца у вектары, тады правілы з семантычнаю близасцю будуць выяўляцца нават калі формулівацыя разная (“выпуск за хворобу” проты “права на відпачык за хворобу”).

    4. Адзыявленне з MMR

    Простая метода падобнасці top-k можа вернуць чатыры фрагмента палітакі пра выпускны час, якія здаюцца майже дубліруючыміся:

    Chunk 1 → Leave policy
    Chunk 2 → Leave policy
    Chunk 3 → Leave policy
    Chunk 4 → Leave policy
    

    Максимальная маргінальная рэлевантнасць санаважвае рэлевантнасць і разнообразнасць. Большыя кандыдацкія запасы fetch_k, а пасля — выбор заканчоўных k за дапамой MMR, зменшаюць рэданданс:

    10,000 chunks
          ↓
    Similarity search
          ↓
    20 candidate chunks
          ↓
    MMR
          ↓
    4 diverse + relevant chunks
          ↓
    LLM
    

    5. Адзыявленне з урахоўваннем історыі

    Пытанні на кшталт «А як з менаджерамі?» пасля адпаведзі на пытанне пра годзінны выпуск сама по сабе є неяснымі. Крок з урахоўваннем історыі перапісвае запит, выкарыстоўваючы історыю размовы, прытаму як адбываецца адзыявленне:

    Conversation History
            +
    Current Question
            ↓
           LLM
            ↓
    Standalone Search Query
    

    Это аддзеляе контекстуалізацыю запиту (што мела на увазе адпаведальнік?) ад генеравання адпаведзі (што павінна быць адпаведзь, вяручы дакументам?).

    6. Генераванне адпаведзі на адной падставе

    Зявілыя фрагменты падаюць у запрос, які прыказвае модэлі выкарыстоўваць толькі дакументы з канпаніі, ухілляцца ад стварэння новых правілаў, паказваць выключэнні, залічвацца канкрэтнымі і прызнаваць недастаткі. Архітектура: запит → контекстуалізацыя → прыстрой для адзыскання → дакументы → запрос для перагляду → LLM → адпаведны адказ. Модэлі пішуць прозу; корпус супляе факты.

    7. Чаму LangGraph

    Калі колькасць стадзій зрастае — аправарэнне, модерация, выяўленне втрымкі інфармацыі, обробка запытаў, адзысканне дакументаў, генераванне, памяць, стварэнне апуса — лінейны ланцуг становіцца кранкавым. LangGraph моделюе рабочы процес як станы і вузлы:

                    User Input
                        ↓
                   Validation
                        ↓
                  Guardrails
                    ↙     ↘
              Safe          Unsafe
               ↓               ↓
           RAG Workflow      Reject
               ↓
          Final Response
               ↓
           Conversation
            Management
    

    Граф стае простым для расшырэння, калі ўжо не як адна вялікая функцыя.

    8. Нормы

    Уводныя даны для працы трэба пераканаць пры выкарыстоўванні тэхналогіі RAG:

    • Модерация — раннее блакаванне контэнту, які наражае на правіла
    • Выяўленне втрымкі запросаў — адхоўленне атак у стыле “ігнораваць пярэднія інструкцыі…”

    Порядак мае значэнне: даныя з вводу корыстніка → перакантрольванне безпекі → RAG, а не даныя з вводу корыстніка → сыры ЛЛМ.

    9. Памяць дыялогу і стварэнне апূর্তання

    Асистэнты, якія ведуць дыялог у кальце, патрабуюць історію, але необмежаныя транскрыпцыі спалюють токены. Стварэнне апূর্তання старыях кальцеў дапамагае зберагчы важлівую інфармацыю, адночасна обмежваючы актыўны контэкст — гэта баланс межа зберагчым і вартасцю.

    10. Адгукненне па рэтрыбуцыі

    Адказ можа выглядаць плавным, хоць рэтрыбуцыя не выйшла. Неабходна пераканацца, чы рэгулярныя фрагменты тэксту былі прыняты, а не толькі чы тэкст узяўся. Неабходна адгукнуцца пра якасць рэтрыбуцыі, стварэнне генераванага тэксту і прыменне яго як окремых аспектаў.

    11. Цітаты з джэрел

    Краща вжываць фразы на кшталт «Саветнікі атрымоўваюць 20 дзён ўстаўкі на год (Палітыка устаўкі §3)», чым простыя твэрджэння. Цітаты павышаюць довер'е, спрыяюць адлагоджэнню проблем і забезпечваюць возможнасць адстэплення, калі саветнікі можаць ачынаць орыгінальны PDF.

    12. Экспорт дыялогу у формате PDF

    Экспорт размовы у формате PDF дазволяе працавікам захаваць ўсё для пазнейшага вжытку. Це деталь, якая паказвае, што система прызначаная для рэальной работы, а не толькі для тымчасовага чату.

    Заканчэнне

    Працоўны асистент у формате HR RAG складаецца зэйчоў: прыёму даных, стратэгіі пошуку, перапісвы размовы, аргументацыі, керавання графамі, правілаў, ацэнкі та цітатаў. LangChain і LangGraph дапамагаюць аб’еднаваць гэтыя етапы; Chroma і MMR вплываюць на тое, што можа бачыць модель. Непрыемлівая правіла продукту застаецца такой: адпаведзі прадукту выходзяць з утверждзеных дакументаў, а не з памяці моделі пра інтэрнет.

    Выборы дизайна, якія маюць значэнне на практыцы

    Размер частак і ступень перакрыцця не ўжо толькі косметычныя праблемы. Занадта великі частакі слабяць сигнал умяшчэння; занадта маленькія частакі втрачаюць абмежэння, накладваныя суседзяючымі правіламі. Перакрыцце дапамагае, калі правіло распрастраняецца па межы. Метаданы — гэта не проста декоратыўная элемент; без назвы файлу і падказак пра разделы цітаты становяцца нечыстымі, а наборы для ацэнкі — важкімі да оценкі.

    Параметры MMR (fetch_k, k, diversity lambda>) трэба налаштаваць на адповіднасць з наборам пытанняў з пазначкамі, а не на інтуіцыю. Колекцыя кандыдатаў, якая занадта мала, ніколі не прадстаўляе разнаобразных фрагментаў; колекцыя, якая занадта велика, витрачае час на обробку.

    Перапісваўанне з урахоўваннем історыі не павінна ствараць новых фактов. Крок перапісваўання должен толькі расширваць займенніки і непূরныя запиты ў самостойныя запиты для пошуку. Якщо модель перапісваўання пачне даўаць адпаведзі, система пошуку ніколи не побачыць чыстага запиту.

    Захоўнікі павінны быць налагоджаны ў пераддзеўстві рэтрыбюцыі. Модерацыя і выкліканне адкрыць патогеннага коду, якія выкананы пасля таго, як модель вже пераканалася текст прайватной політыки, є запазджанымі. Неабяжна адхіліць падозру на вставку коду; дазволіць такое толькі там, дзе політыка продукту чыста прыменяе мяккі блокаванні з логаванням.

    Ацэнка павінна включаць як рэтрыбюцыю (recall@k адпаведных ідэнтыфікатараў дакументаў), так і генераванне (аддаслужнасць да перакананага тексту). Які-небудзь адпаведны адказ, але на базе некоректнага клазу, таксама ўважаецца невыпаннем задачы. Зберагаць следы: перапісаны запит, перакананыя ідэнтыфікатары, фінальны адказ, спіс цитатаў.

    Streamlit (או будзь-які просты інтерфейс) павінен чытка адображаць цитаты і статусы “невядома”. Савецкія працавальнікі больш дазвараюць системам, якія прызнаюць своия недастаткі, чым тым, якіе вигадваюць розмаўныя правілы пра відпачынак.

    Экспорт у PDF ёсць функцыяю зберагачвання: людзі вставляюць адказы на праблемы ў тікеты. Экспортаваны текст трэба спрыяваць як потэнцыйна чутлівы і прыменяць тыя ж правіла доступу, што і пад час чат-сесіі.

    У канцы, нехай шлях адпрацоўкі графа застаецца зрозумелым. Новыя інжынеры павінны магчыма быць накрэсліць ляму параболізацыі: апраўленне → перапісваўанне → запыт → генераванне → адпаведзь, не падаючыся ў неабавязковыя галузі. Неабавязковыя галузі (падсумованне, экспорт) з’яўляюцца як окремыя вузлы, а не ўтвараюць структуру внутры процесу генеравання.

    Такая дисцыпліна ператварае дэманстрацыю RAG за выходныя на тое, што каманда па кадрам можа прыменіць, не баячыся тых, каго называюць „галюцинаціямі правіл“.

    Размешчэнне элементаў у часовай шкале

                        HR DOCUMENTS
                             │
                             ▼
                    DOCUMENT INGESTION
                             │
                    Chunking + Metadata
                             │
                             ▼
                        EMBEDDINGS
                             │
                             ▼
                         CHROMADB
                             │
                             ▼
                        RETRIEVER
                        (MMR Search)
                             │
                             │
    USER ──→ GUARDRAILS ─────┤
                             │
                             ▼
                  HISTORY-AWARE QUERY
                      CONTEXTUALIZATION
                             │
                             ▼
                        RETRIEVAL
                             │
                             ▼
                    RELEVANT DOCUMENTS
                             │
                             ▼
                      QA PROMPT + LLM
                             │
                             ▼
                      GROUNDED ANSWER
                             │
                        ┌────┴────┐
                        ↓         ↓
                    Citations   Memory
                                  │
                                  ▼
                             Summarization
                                  │
                                  ▼
                             PDF Export
    

    Першы дзень частаўсе пры «вбудовванні PDF-файлаў і чате». З другага па дзесяты дзень з’яўляюцца рэальныя элементы працы: схемы метаданых, налаштаванне MMR, патроны для перапісву, механізмы модерацыі, класыфікаторы для введэння дадзеных, табліцы для ацэнкі, форматаванне цітатаў і стыканне розмов. Якщо праігнораваць гэтыя крокі, система будзе добра працаваць з простымі запитамі, але заваліцца пад час наступных запытоў, з агрэсівнымі патронамі чы ў разе пошуку майже ідэнтычных дадзеных.

    LangChain памагае з’ўязваць об’екты модэля і средства пошуку; LangGraph памагае зробіць логіку керування прозрачной. Ні адна з іх не можа заменіць рашэння пра тое, якія папкі HR є автантонічнымы, хто можа запытаць пра якія правілы і як у інтэрфейсе відображацца «не вядомы» элементы. Гэтыя рашэння павінны быць у дакументах да проекту разам з дыяграмамі графа.

    Калі ў працэйнай суперактывацыі выйшла проблема, найшырэзны ўзбіранак для дыягностыкі зазвычай такі: пераглянуць перапісаны запит, апісаць ідэнтыфікаторы отриманых частак, прачытаць гэтыя часткі, а пасля — прачытаць восьпамятанне, на якое быў створены запит. Якщо гэтага падходу няма ў логах, спачатку выправіце можлівасць аналізу, перш чым дадаць новую модель.