Разработка политики в области управления персоналом с использованием RAG, LangChain и LangGraph
Потребление данных, MMR, перепись с учетом истории, обоснованные ответы, ограничения, оценка, цитаты и оркестрация графов для помощника по кадровой политике.
Пошаговое руководство, охватывающее процесс ввода данных, поиск информации из MMR, запросы с учетом истории, проверки безопасности, механизмы оценки и пользовательский интерфейс для многократных диалогов.
Введение
Для корпоративных систем управления персоналом недостаточно просто генерировать плавные ответы. Помощник по правилам не должен самостоятельно создавать правила отпусков на основе предварительной обучающей выборки; он должен запрашивать утвержденные документы и обосновывать каждое заявление на основе этих источников. Именно это и предназначено для технологии генерации с усилением поиском (RAG).
Модульная система вопросов и ответов по политике в области управления персоналом в производственном стиле может объединять 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, снижает избыточность:
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, избегать выдумки правил, указывать исключения, сохранять краткость и признавать пробелы в знаниях. Архитектура: вопрос → контекстуализация → механизм поиска → документы → промпт для проверки качества → большая языковая модель → основанный на фактах ответ. Модель пишет прозу; корпус предоставляет факты.
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, лямбда разнообразия) следует настраивать на основе набора заданий с метками, а не интуиции. Пул кандидатов, слишком маленький, никогда не позволяет найти разнообразные фрагменты текста; пул, слишком большой, приводит к потере времени на обработку.
При переписывании с учетом истории нельзя выдумывать факты. Шаг переписывания должен лишь расширять местоимения и незавершенные запросы в отдельные поисковые запросы. Если модель переписывания начинает отвечать на вопросы, система поиска никогда не получает чистого запроса.
Механизмы контроля должны применяться до получения данных. Модерация и обнаружение вставок, выполняемые после того, как модель уже ознакомилась с текстом политики конфиденциальности, слишком поздние. При подозрении на вставку следует сразу отклонить запрос; разрешать запросы можно только в тех случаях, когда политика продукта прямо предусматривает мягкую блокировку с логированием.
Оценка должна учитывать как процесс поиска (коэффициент воспроизведения ожидаемых идентификаторов документов), так и качество генерации (степень соответствия полученному тексту). Красивый ответ, основанный на неверном пункте политики, также считается неудачным. Необходимо хранить следы: переписанный запрос, полученные идентификаторы, окончательный ответ и список цитат.
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-данных, которые считаются авторитетными, определению того, кто может задавать вопросы по каким правилам, и описанию того, что считается «неизвестным» в интерфейсе. Такие решения должны быть указаны в документации к проекту рядом с диаграммами структуры.
Когда в производственной среде возникают проблемы, самый быстрый способ отладки обычно заключается в следующем: проверить переписанный запрос, вывести список идентификаторов полученных фрагментов, прочитать эти фрагменты, а затем прочитать исходный запрос. Если эти данные отсутствуют в логах, необходимо улучшить возможности отслеживания ситуации перед добавлением новой модели.