Почему файлы регламентов не работают «из коробки»
Распространённая ошибка при внедрении ИИ-ассистента — загрузить в систему объёмный PDF-документ с общим регламентом компании или должностными инструкциями на 100 страниц.
В таком файле таблицы перемешаны со сносками, условия акций накладываются на базовые прайс-листы, а важные ограничения спрятаны в примечаниях. Когда языковая модель ищет ответ методом семантического поиска по фрагментам (RAG — Retrieval-Augmented Generation), в поисковую выдачу попадают случайные абзацы. Модель смешивает данные разных филиалов, путает цены и сообщает клиенту несуществующие условия.
Чтобы ассистент отвечал чётко и без фантазий, исходные знания компании необходимо разделить на структурированные единицы.
Правило атомарности: одна статья — одна сущность
Базовый принцип надёжной базы знаний — атомарность. Каждая запись должна быть посвящена строго одной теме и отвечать на конкретный вопрос клиента:
- Неправильно: общий документ «Все услуги стоматологии, цены и врачи на 2026 год». При обновлении графика одного доктора приходится перезагружать весь файл, а эмбеддинги размываются.
- Правильно: отдельная карточка на каждую процедуру («Профессиональная чистка зубов Air Flow»), где указаны: показания, противопоказания, длительность приёма, стоимость в тенге, адреса филиалов и имена принимающих специалистов.
При такой структуре поисковый модуль извлекает именно тот фрагмент, который нужен для ответа на запрос, без захвата лишнего шума.
Контекстный поиск (Contextual Retrieval)
В 2024 году команда Anthropic опубликовала метод Contextual Retrieval, позволивший снизить процент ошибок поиска в базах знаний почти вдвое [1].
Суть проблемы традиционного дробления текста (chunking): когда текст нарезается на куски по 300–500 токенов, фрагмент часто теряет контекст. Например, абзац гласит: «В этом случае предоплата составляет 50% от суммы счёта». Если модель не знает, о какой услуге или филиале идёт речь, векторный поиск выдаст этот кусок на любой вопрос о предоплате.
Решение состоит в предварительном обогащении каждого фрагмента кратким поясняющим заголовком перед индексацией:
- Исходный кусок: «Предоплата 50% вносится не позднее 24 часов до начала бронирования зала».
- Обогащённый контекстом кусок: «Услуга: Аренда переговорной комнаты в коворкинге на Достык. Правила бронирования: Предоплата 50% вносится не позднее 24 часов до начала бронирования зала».
Поиск по такой базе находит точные совпадения и не подмешивает условия других услуг.
Гибридный поиск: плотные векторы плюс BM25
Чисто векторный семантический поиск отлично понимает синонимы («сколько стоит вылечить кариес» и «цена пломбы»), но часто пасует перед точными артикулами, юридическими аббревиатурами и географическими названиями в Казахстане (например, названия улиц, жилых комплексов или медицинских препаратов).
Для корпоративного применения отраслевым стандартом стал гибридный поиск [3]:
- Dense Retrieval (векторный поиск) — сопоставляет смысл вопроса и формулировок клиента в WhatsApp.
- Sparse Retrieval (BM25 / полнотекстовый индекс) — гарантирует точное нахождение названий препаратов, регламентных номеров и специфических терминов.
- Reranker (переранжирование) — выбирает топ-3 наиболее подходящих карточки и передаёт их языковой модели вместе с системным промптом.
Защита от выдумок: строгое правило отказа
Главная мера защиты от дезинформации — системный запрет на додумывание. В промпт агента закладывается правило верификации:
- Отвечать строго на основе переданных фрагментов базы знаний.
- Если информации для уверенного ответа недостаточно, прямо сообщить об этом клиенту: «У меня нет точной информации по этому вопросу. Сейчас переключу диалог на администратора, он уточнит детали».
- При любых нестандартных жалобах, претензиях или вопросах о здоровье немедленно привлекать дежурного сотрудника.
Такой подход защищает бизнес от юридических рисков и сохраняет доверие клиентов.