Палітра RAG для падчыннай політыкі кадроў з LangChain і LangGraph
Прыем даных, MMR, перапісваўка з урахоўваннем історыі, адпаведныя на адповедзі, правілы карантэна, ацэнка, цітаты і оркестрацыя графаў для падрабніка з правілаў кадровай справы.
Паспорт, які раскрывае процес прыему даных, адгутаванне MMR, запиты, які урахоўваюць історыю, перакананні ў безпецы, хукі для ацэнкі і UX для чату з калькама роўнаў.
Введэнне
Для аддзела кадраў у большых компаніях недастатнька проста генераваная адпаведзь. Памочны прыстрой для правіл не павінен выдумваць правіла выпачкі на адвароте пад час прадзейнавання. Ён должен адгутаваць затверджаныя дакументы і падкрэпляць кожны тверджэння цімі джэрамі. Гэта і є задача методу генеравання з адгутаваннем даных (RAG).
Модульная система запитанняў і адказоў па правілам пра кадры у стыле прымення можа аб’еднаваць Python, LangChain, LangGraph, чат-модель сумесную з OpenAI, ChromaDB, Streamlit, эмбеддінгі, методы адзыскання дадзэнняў MMR, перапісва запитоў з урахаваннем історыі, проектаванне запрошэнняў, модерацыю вхідных дадзэнняў, перакантрольванне вставкі запрошэнняў, ацэнку адзыскання дадзэнняў, памяць для канверсацый, стварэнне падсумкаў і экспорт у формат PDF. Мета — не дэмаверсія чат-бота, а система RAG, якая серьёзна ставіцца да якосці адзыскання дадзэнняў, контексту канверсацій, безпекі, ацэнкі і зручнасці выкарыстоўвання.
1. Проблема
Калі хтось запытае: «Сколькі дзён відпачыку з прычыны хворобы дазволены?», звычны LLM можа выдумаць адказ. У свою чаргу, асистент з пытанняў пра кадры должен:
- Зрозумець запыт
- Пашукаць дакументы організацыі, прынятныя для кадровай справы
- Адзыскаць найболей релевантныя часткі
- Перадаць гэтыя часткі моделі
- Стварыць адказ, базаваны на іх
Алгорытм работы: дакументы кадровага аддзелу → ўваходжэнне → разбіўка на часткі + метаданы → вектарныя представленні → 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 є автантонічнымы, хто можа запытаць пра якія правілы і як у інтэрфейсе відображацца «не вядомы» элементы. Гэтыя рашэння павінны быць у дакументах да проекту разам з дыяграмамі графа.
Калі ў працэйнай суперактывацыі выйшла проблема, найшырэзны ўзбіранак для дыягностыкі зазвычай такі: пераглянуць перапісаны запит, апісаць ідэнтыфікаторы отриманых частак, прачытаць гэтыя часткі, а пасля — прачытаць восьпамятанне, на якое быў створены запит. Якщо гэтага падходу няма ў логах, спачатку выправіце можлівасць аналізу, перш чым дадаць новую модель.