Как я строил RAG-агента для HR-рекомендаций: разбор архитектуры, проблем с BDD и сформированных skills

Почему HR-агент — это не поиск по вакансиям

Когда заказчик сказал "сделай нам AI-агента для HR рекомендаций", я сразу понял: это будет не про поиск кандидатов. Это про другое. HR-специалист каждый день решает десятки вопросов, которые не укладываются в шаблоны: "Как мотивировать этого разработчика, который хочет уйти?", "Какие компенсации предложить в условиях кризиса?", "Как провести сокращение без судебных исков?".

Проблема номер один: у компании есть горы документов — политики, регламенты, прецеденты, решения судов, внутренние письма. Но никто не читает их целиком. HR работает по памяти и интуиции. А потом получает иск от уволенного сотрудника за нарушение процедуры.

Архитектура: что скрывается за простым чат-интерфейсом

Снаружи — обычный чат. Внутри — система из пяти компонентов, где каждый решает свою задачу. Если смешать их в один промпт, получится каша, которую невозможно отлаживать.

1 Intent Classifier: понимаем, что хочет пользователь

HR спрашивает: "Что делать, если сотрудник опоздал на 3 часа?". Это про дисциплинарное взыскание? Или про переработки? Или про удалённую работу? Классификатор на базе GPT-4.5-mini (самая новая версия на февраль 2026) определяет категорию запроса за 0.2 секунды и 0.0005 доллара.

# Пример классификации интента
intent_categories = [
    "disciplinary_action",  # Дисциплинарные взыскания
    "termination",         # Увольнение
    "compensation",        # Компенсации и выплаты
    "remote_work",         # Удалённая работа
    "data_protection",     # Защита персональных данных
    "other"               # Всё остальное
]

prompt = f"""Классифицируй запрос HR специалиста:
Запрос: {user_query}

Выбери ОДНУ категорию из списка: {', '.join(intent_categories)}
Верни только название категории."""

2 Context Builder: собираем релевантные знания

Здесь начинается магия RAG. Но не та, про которую пишут в туториалах. Мы используем три источника знаний одновременно:

• Векторный поиск по эмбеддингам документов (используем text-embedding-3-large, последнюю модель OpenAI)
• Лексический поиск по ключевым терминам ("опоздание", "прогул", "дисциплинарное взыскание")
• Граф знаний — связи между документами, которые мы построили заранее

3 Skill Selector: выбираем нужный навык

Skills — это не просто промпты. Это структурированные знания с чёткими входами и выходами. Каждый skill знает, какие данные ему нужны и какой формат ответа он возвращает. Подробнее о skills читайте в статье "Agent Skills: как упаковать знания для LLM-агентов".

4 Response Generator: генерируем ответ с контекстом

GPT-4.5 (релиз ноября 2025) получает собранный контекст, выбранный skill и инструкции по формату. Важный нюанс: мы не просто скармливаем текст. Мы структурируем его:

# Структура контекста для LLM
context_structure = {
    "primary_document": "Основной документ по теме",
    "supporting_docs": ["Дополнительные документы"],
    "legal_references": ["Ссылки на законы"],
    "precedents": ["Похожие случаи в компании"],
    "risks": ["Потенциальные риски"],
    "action_steps": ["Конкретные шаги"]
}

5 Validator: проверяем ответ на ошибки и риски

Самый важный компонент. LLM может "галлюцинировать" или дать опасный совет. Валидатор проверяет:

• Соответствие законодательству (сверяет с актуальными версиями законов на 2026 год)
• Наличие ссылок на внутренние документы
• Отсутствие противоречий в рекомендациях
• Язык ответа (не должно быть двусмысленных формулировок)

BDD: как тестирование требований сломало первую версию

Behavior Driven Development звучит красиво. "Пишем требования на естественном языке, тесты генерируются автоматически". На практике это оказалось ловушкой.

Мы начали с классических BDD-сценариев:

Feature: Дисциплинарные взыскания
  Scenario: Сотрудник опоздал на работу
    Given сотрудник опоздал на 3 часа
    When HR специалист запрашивает рекомендации
    Then система должна предложить план действий
    And план должен включать запрос объяснений
    And срок ответа должен быть 2 рабочих дня

Проблема первая: неоднозначность естественного языка. "Опоздал на 3 часа" — это один раз? Или систематически? С уважительной причиной или без? BDD-сценарии не учитывали контекст, который критически важен в HR.

Проблема вторая: жёсткие проверки. "Срок ответа должен быть 2 рабочих дня" — но что если день опоздания был перед праздниками? Или сотрудник в отпуске? Или на больничном? Система, построенная на жёстких правилах, ломалась на первом же реальном случае.

Как мы это починили

Вместо жёстких BDD-сценариев мы перешли на контекстно-зависимые тесты:

1. Тесты на граничные случаи: что если сотрудник опоздал на 3 часа, но предупредил? Что если это первый раз за год? Что если у него маленький ребёнок?
2. Тесты на противоречия: проверяем, что система не рекомендует взаимоисключающие действия
3. Тесты на безопасность: агент никогда не должен советовать нарушать закон или внутренние политики
4. Тесты на ссылки: каждая рекомендация должна иметь обоснование в документах

Для автоматизации используем комбинацию: pytest для юнит-тестов, playwright для end-to-end тестов и собственную систему валидации ответов LLM. Подробнее о тестировании AI-систем читайте в статье "AI-агенты генерируют код быстрее, чем вы успеваете его проверить".

Skills: как упаковать экспертизу для LLM

Skills — это сердце системы. Не промпты, не цепочки вызовов, а именно навыки. Каждый skill включает:

• Метаданные: название, версия, область применения, ограничения
• Входной schema: какие данные нужны для работы (типизировано через Pydantic)
• Контекстные шаблоны: как собирать релевантные знания из RAG
• Промпт-шаблон: структура запроса к LLM с местами для подстановки
• Выходной schema: формат ответа (JSON schema)
• Валидаторы: правила проверки ответа

# Пример skill для дисциплинарных взысканий (упрощённо)
from pydantic import BaseModel
from datetime import date
from typing import Optional, List

class DisciplinaryInput(BaseModel):
    violation_type: str  # "опоздание", "прогул", "невыполнение обязанностей"
    violation_date: date
    employee_tenure: int  # стаж в месяцах
    previous_warnings: int = 0
    has_explanation: Optional[bool] = None
    
class DisciplinaryOutput(BaseModel):
    action_plan: List[str]
    required_documents: List[str]
    deadlines: dict
    risks: List[str]
    references: List[str]  # ссылки на документы

Главный секрет: skills не создаются вручную. Мы используем автоматическую генерацию из документов. Загружаем "Положение о дисциплине", и система сама выделяет ключевые процедуры, сроки, документы. Это похоже на подход из статьи "Skill Seekers v2.5.0: автоматизируем создание RAG-навыков", но с адаптацией под HR-контекст.

Проблемы, которые мы не ожидали встретить

1. Конфиденциальность vs. Контекст

HR-документы содержат персональные данные, конфиденциальную информацию. Мы не можем просто загрузить их в векторную базу. Решение: двухуровневая система:

• Публичный слой: обезличенные документы, политики, регламенты
• Приватный слой: конкретные случаи, решения, прецеденты (доступ только по запросу с авторизацией)

2. Юридическая ответственность

Агент даёт рекомендации. Кто отвечает, если рекомендация окажется неправильной? Мы добавили три уровня предупреждений:

3. Устаревание знаний

Трудовое законодательство меняется каждый год. В 2026 году уже действуют поправки, принятые в 2025. Решение: система мониторинга изменений:

1. Ежедневная проверка официальных источников на изменения законов
2. Автоматическое оповещение, если документ устарел
3. Флаг "требует проверки" для рекомендаций, основанных на изменённых нормах

Что работает в 2026 году

После шести месяцев разработки и трёх месяцев пилота:

• Скорость ответа: 2-4 секунды на сложный запрос
• Точность: 87% рекомендаций подтверждаются юристами компании
• Экономия времени HR: 30-40 минут на каждый сложный кейс
• Снижение рисков: система обнаружила 14 потенциальных нарушений процедур

Но главный результат не в метриках. Главное — HR-специалисты начали доверять системе. Не потому что она всегда права, а потому что она всегда показывает источники своих рекомендаций. Можно открыть документ и проверить.

Если будете строить своего HR-агента

Не начинайте с архитектуры. Начните с самого болезненного кейса в работе HR. Возьмите один тип запросов (например, увольнение по инициативе работодателя) и сделайте его идеально. Потом добавляйте следующий.

Не пытайтесь заменить HR-специалиста. Ваша цель — дать ему суперсилу: мгновенный доступ ко всем знаниям компании. С проверкой на ошибки и риски.

И самое важное: тестируйте на реальных случаях с самого начала. Теоретические сценарии из учебников по трудовому праву не имеют ничего общего с тем, что происходит в реальных компаниях. Как показал наш провальный кейс, разрыв между теорией и практикой убивает AI-проекты быстрее, чем любые технические проблемы.