Как научить ИИ-агента внутренним регламентам компании

Компании массово внедряют чат-ассистентов поверх GPT-4o, Claude или локальных моделей вроде Llama и хотят, чтобы те отвечали не выдумками из интернета, а по внутреннему регламенту: как оформить отпуск, какой лимит на командировочные, куда эскалировать инцидент. Проблема в том, что базовая модель ничего не знает о ваших документах — её обучали до того, как вы их написали. Способов сшить модель с регламентами три, и они отличаются на порядки по стоимости и срокам внедрения.

Три способа и чем они различаются

Выбор сводится к тому, где живут знания о регламентах: в промпте, во внешней базе или в весах самой модели.

System prompt: положить правила прямо в запрос

Самый простой вариант — вставить текст регламентов в системное сообщение, которое модель видит перед каждым вопросом пользователя. Работает мгновенно, кода почти не требует. Ограничение — размер контекстного окна¹: у GPT-4o и Claude оно измеряется десятками и сотнями тысяч токенов, но целый корпус кадровых, финансовых и ИБ-регламентов туда обычно не влезает, а даже если влезает — вы платите за все эти токены на каждом запросе.

Подходит, когда правил немного: одна политика на пару страниц, скрипт для колл-центра, шаблон ответа. Как только документов становятся десятки, промпт превращается в свалку, и модель начинает терять детали в середине длинного текста.

RAG: подтягивать нужный кусок по запросу

RAG² — сегодня рабочая лошадка для корпоративных ассистентов. Документы режут на фрагменты, превращают в векторы и складывают в базу. На каждый вопрос система ищет наиболее близкие по смыслу фрагменты и подкладывает их модели вместе с вопросом. Модель отвечает по свежему тексту, а не по памяти.

Плюсы: регламент обновили — переиндексировали, и ответы поменялись без переобучения модели. Можно показать источник: «согласно разделу 4.2 положения об отпусках». Минусы: качество ответа упирается в качество поиска. Если фрагменты нарезаны плохо или база проиндексирована криво, модель получит нерелевантный кусок и уверенно ответит мимо.

Дообучение: зашить знания в веса

Дообучение³ (fine-tuning) меняет саму модель на ваших данных. Это дорого, требует размеченных примеров и специалистов, и главное — фактические знания через дообучение передаются плохо: модель усваивает стиль и формат ответов, но конкретные цифры лимитов и сроков всё равно надёжнее держать в RAG. Обновили регламент — дообучать заново.

Дообучение учит модель как отвечать. RAG отвечает на вопрос что сейчас написано в регламенте. Путать эти задачи — типичная ошибка, за которую платят бюджетом и галлюцинациями в проде.

Сравнение подходов

Как собрать RAG-ассистента по регламентам: порядок шагов

1. Соберите и почистите документы. Выгрузите актуальные версии регламентов, уберите устаревшие редакции, отметьте дату каждого. Модель будет цитировать то, что вы ей дали, — мусор на входе даёт мусор на выходе.
2. Нарежьте на фрагменты. Обычно по смысловым блокам или разделам, а не механически по числу символов. Слишком крупные куски разбавляют ответ, слишком мелкие теряют контекст.
3. Постройте векторный индекс. Прогоните фрагменты через модель эмбеддингов и сложите в векторную базу.
4. Настройте поиск и промпт. На вопрос система достаёт релевантные фрагменты и подставляет их модели с инструкцией: отвечать только по предоставленному тексту, при отсутствии ответа честно говорить, что данных нет.
5. Проверьте на реальных вопросах. Соберите список того, что сотрудники спрашивают на самом деле, и прогоните ассистента. Смотрите не на красоту формулировок, а на фактическую точность.
6. Настройте обновление. Договоритесь, кто и как переиндексирует базу при смене регламента, иначе через полгода ассистент будет цитировать отменённые правила.

Кому что подходит

System prompt хватит, если: у вас одна-две короткие политики, ассистент нужен для узкой задачи (скрипт поддержки, шаблон письма), и документы почти не меняются. Запускается за день.

RAG — если: регламентов десятки или сотни страниц, они регулярно обновляются, а сотрудникам важно видеть, откуда взят ответ. Это дефолтный выбор для внутреннего HR-бота, справочной по ИБ-политикам, ассистента для новичков.

Дообучение стоит рассматривать, если: вам нужен строго определённый стиль и формат ответов (например, юридический тон или фиксированная структура), у вас есть размеченные примеры и ML-команда. Даже тогда конкретные факты держите в RAG поверх дообученной модели, а не в её весах.

Чего не стоит делать почти никому: пытаться загнать весь корпус документов в контекстное окно на каждый запрос ради простоты — это дорого по токенам и ненадёжно по точности.

Риски, о которых молчат в презентациях

Первый — утечка данных. Если вы отправляете внутренние регламенты в облачный API, проверьте условия обработки данных провайдера и требования вашей службы ИБ. Для чувствительных документов рассматривают локальные модели, разворачиваемые в своём контуре.

Второй — галлюцинации. Даже RAG-ассистент способен уверенно достроить ответ, если поиск вернул близкий, но не тот фрагмент. Отсюда правило: ассистент должен отвечать «в регламентах этого нет» вместо правдоподобной выдумки, и по спорным вопросам направлять к живому человеку.

Третий — устаревание. Регламент меняется, а индекс — нет. Без процесса обновления ассистент тихо превращается в источник неверных инструкций, и это опаснее, чем отсутствие ассистента вовсе.

¹ Контекстное окно — максимальный объём текста (в токенах), который модель может держать в памяти за один запрос: и ваш промпт, и ответ.

² RAG (Retrieval-Augmented Generation) — подход, при котором к запросу пользователя автоматически подставляют найденные во внешней базе релевантные фрагменты, и модель отвечает, опираясь на них.

³ Дообучение (fine-tuning) — дополнительное обучение готовой модели на ваших примерах, меняющее её веса под конкретную задачу или стиль.