РПА з політикою у сфері кадрів, створена за принципами виробництва, з використанням LangChain та LangGraph
Інгестія даних, MMR, переписування з урахуванням історії, обґрунтовані відповіді, захисні механізми, оцінка, посилання та оркестрація графів для асистента з політики у сфері кадрів.
Покроковий огляд, який стосується отримання даних, пошуку інформації з MMR, запитів з урахуванням історії, перевірок безпеки, механізмів оцінки та користувацького інтерфейсу багатокрокових розмов.
Вступ
Для корпоративних систем кадрів недостатньо просто створювати плавні генеративні відповіді. Асистент з правилами має отримувати інформацію з схвалених документів, а не вигадувати правила відпусток на основі попереднього навчання. Кожне твердження має ґрунтуватися саме в цих джерелах. Саме це є завданням технології Retrieval-Augmented Generation (RAG).
Модульна система типу Q&A для політики у сфері кадрів у промисловому стилі може поєднувати Python, LangChain, LangGraph, чат-модель, сумісну з OpenAI, ChromaDB, Streamlit, ембеддинги, методи пошуку MMR, переписування запитів з урахуванням історії, проектування запитів, модерацію вхідних даних, перевірку на введення змінених запитів, оцінку результатів пошуку, конверсаційну пам’ять, стиснення інформації та експорт у формат PDF. Метою є не демонстраційний чат-бот — це система RAG, яка серйозно ставиться до якості пошуку інформації, контексту розмови, безпеки, оцінки та зручності використання.
1. Проблема
Коли хтось запитує: «Скільки днів хвороби дозволено?», звичайний LLM може вигадати відповідь. Натомість асистент з питань кадрів повинен:
- Зрозуміти запит
- Пошукати внутрішні документи організації, пов’язані з кадрами
- Знайти найбільш релевантні розділи
- Передати ці розділи моделі
- Сформувати відповідь, засновану на цих даних
Основний процес: документи HR → завантаження → розділення на частини + метадані → ембеддинги → 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, зменшує Redundантність:
10,000 chunks
↓
Similarity search
↓
20 candidate chunks
↓
MMR
↓
4 diverse + relevant chunks
↓
LLM
5. Пошук з урахуванням історії
Питання на кшталт „А як щодо менеджерів?“ після відповіді про щорічну відпустку саме по собі є неоднозначними. Крок з урахуванням історії переписує запит, використовуючи історію розмови, перед пошуком:
Conversation History
+
Current Question
↓
LLM
↓
Standalone Search Query
Це розділяє контекстуалізацію запиту (що мав на увазі користувач?) від генерації відповіді (що має бути сказано з урахуванням документів?).
6. Генерація відповідей на основі фактів
Отримані фрагменти подаються у вигляді запиту, який просить модель використовувати лише документи HR, уникати вигадування правил, вказувати винятки, бути лаконічною та визнавати прогалини. Архітектура: запит → контекстуалізація → механізм пошуку → документи → запит для перевірки якості → LLM → обґрунтована відповідь. Модель пише прозу; корпус надає факти.
7. Чому LangGraph
Чим більше етапів — перевірка, модерація, виявлення втручань, обробка запитів, пошук, генерація, пам’ять, узагальнення — тим більш крихкою стає лінійна послідовність. LangGraph моделює робочий процес у вигляді станів та вузлів:
User Input
↓
Validation
↓
Guardrails
↙ ↘
Safe Unsafe
↓ ↓
RAG Workflow Reject
↓
Final Response
↓
Conversation
Management
Граф легше розширювати, ніж одну величезну функцію.
8. Ограничення
Вхідні дані для продакшену потребують перевірки перед використанням RAG:
- Модерація — раннє блокування контенту, що порушує правила
- Виявлення втручань у запити — відмова у обробці атак типу „ігноруй попередні інструкції… “
Порядок має значення: вхідні дані користувача → перевірки безпеки → RAG, а не вхідні дані користувача → сирий LLM.
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 є авторитетними, хто може запитувати про які правила та як у інтерфейсі виглядають „невідомі“ дані. Ці рішення мають бути включені до документації про проект поруч із схемою графу.
Коли щось йде не так у продакшені, найшвидший шлях для дебаггінгу зазвичай полягає у наступному: перевірити переписану запит, вивести список ідентифікаторів отриманих частин, прочитати ці частини, а потім прочитати вихідний запит. Якщо цього запису немає у журналах, спочатку виправте можливості моніторингу, перш ніж додавати ще одну модель.