Модель уверенно отвечает неверно
Языковая модель без доступа к источникам додумывает пункт регламента и формулирует его правдоподобно. Ошибку замечают только на этапе, когда решение уже принято.
Поддержка решений
Ответ находим в ваших документах, а не в голове сотрудника
Собираем корпоративную базу знаний в поисковый индекс, чтобы специалист получал нужный пункт регламента за секунды. Для решений с ценой ошибки добавляем скоринг и явное объяснение: почему система рекомендует именно этот вариант.
Или сразу: +7 (962) 368-39-51 Telegram
RAG
ответ со ссылкой на пункт документа
hybrid
векторный поиск плюс полнотекстовый
scoring
числовая оценка риска сделки
audit
журнал каждого предложенного решения
Что мешает опираться на ИИ в решениях
Опасения руководителей обычно связаны не с технологией, а с невозможностью проверить, откуда взялся ответ.
Документы живут в семи местах
Регламенты в Confluence, приказы в сетевой папке, письма-разъяснения в почте, исключения — в голове ведущего специалиста. Единого источника правды нет.
Решение нельзя объяснить проверяющему
«Так посчитала модель» не подходит ни внутреннему аудиту, ни регулятору. Нужны признаки, их веса и понятная формулировка оснований.
Знания устаревают быстрее, чем обновляется индекс
Приказ отменён, лимит изменён, появилось письмо-исключение. Если индекс обновляется вручную раз в квартал, система начнёт ссылаться на недействующие нормы.
Права доступа не учитываются при поиске
Один индекс на всю компанию означает, что сотрудник отдела продаж получит в ответе фрагмент документа, который ему читать не положено.
Сотрудники не доверяют подсказкам
После двух-трёх неверных рекомендаций специалист перестаёт открывать систему и возвращается к поиску по папкам. Доверие восстанавливается долго и только прозрачностью.
Состав решения
Собираем систему в четыре слоя: знания, поиск, оценка и интерфейс специалиста.
База знаний и подготовка корпуса
Приводим разрозненные документы к пригодному для поиска виду: чистим дубликаты, режем на смысловые фрагменты, сохраняем ссылки на первоисточник.
- Загрузка регламентов, приказов, инструкций и базы знаний поддержки
- Разбиение на фрагменты с сохранением заголовков и нумерации пунктов
- Дедупликация версий и разметка актуальности документа
- Хранение прав доступа для каждого фрагмента
Гибридный поиск и генерация ответа
Комбинируем векторный поиск по смыслу с полнотекстовым по точным терминам: артикулам, номерам приказов, аббревиатурам.
- Эмбеддинги в Qdrant или pgvector в вашей базе
- Переранжирование кандидатов перед подачей в модель
- Ответ формируется только по найденным фрагментам
- В каждом ответе — ссылка на пункт и версию документа
Скоринг и правила
Для решений с числовой логикой рядом с поиском работает модель оценки: она считает риск, приоритет или вероятность и отдаёт значение вместе с признаками.
- Градиентный бустинг на исторических решениях
- Пороговые правила поверх скоринга для жёстких ограничений
- Вклад признаков в итоговую оценку для каждого случая
- Регулярная проверка на дрейф входных данных
Интерфейс и контроль
Встраиваем подсказки туда, где сотрудник уже работает: в CRM, Service Desk, личный кабинет или Telegram-бот.
- Карточка рекомендации с источниками и уровнем уверенности
- Кнопка «не согласен» с сохранением причины для разбора
- Журнал всех запросов и выданных ответов для аудита
- Отчёты по доле принятых рекомендаций
Как мы запускаем поддержку решений
Начинаем с узкого класса решений, где ошибка не критична, и расширяем зону ответственности системы по мере накопления доверия.
-
01 1 неделя
Выбор класса решений
Определяем, какие решения система будет поддерживать, и как измеряется качество: точность ответа, доля принятых рекомендаций, время поиска.
-
02 2–3 недели
Сбор и подготовка корпуса
Собираем документы, договариваемся о владельцах актуальности, настраиваем регулярное обновление индекса.
-
03 2–3 недели
Прототип и оценка
Готовим набор из 100–200 реальных вопросов с эталонными ответами и измеряем, насколько часто система находит правильный пункт.
-
04 4 недели
Опытная эксплуатация
Подключаем специалистов, разбираем спорные случаи, донастраиваем поиск и передаём систему в поддержку.
Как работает RAG и почему без него нельзя
RAG (retrieval-augmented generation) — схема, в которой модель отвечает не по памяти, а по найденным фрагментам ваших документов. Запрос пользователя превращается в вектор, индекс возвращает несколько ближайших фрагментов, и только они попадают в контекст модели вместе с инструкцией отвечать исключительно по этим данным.
Разница с обычным чатом принципиальна: модель не может «вспомнить» отменённый приказ, потому что в контексте его нет. Если релевантных фрагментов не нашлось, система обязана ответить «в документах нет ответа» — это часть контракта, а не вежливость. Для внутренних регламентов такая честность важнее полноты: неверная ссылка на норму обходится дороже отсутствия ответа.
Почему мы проверяем качество поиска, а не только ответа
Ошибочный ответ почти всегда начинается с ошибочного поиска. Поэтому мы отдельно измеряем качество поисковой выдачи: долю случаев, когда нужный фрагмент попал в топ-5 результатов (recall@5), и позицию правильного фрагмента в списке (MRR). Если правильный пункт регламента не найден на этапе поиска, никакая генерация его не спасёт.
Второй слой оценки — качество ответа: содержит ли он ссылку на источник, не противоречит ли другим найденным фрагментам, нет ли утверждений, которых нет в документах. Для этого собираем набор вопросов с эталонными ответами и проверяем систему при каждом изменении индекса или модели — так обновление не ломает то, что уже работало.
Права доступа: почему один индекс на компанию — плохая идея
Корпоративный поиск обязан учитывать разграничение доступа. Если сотрудник отдела закупок задаст вопрос, система не должна возвращать фрагмент договора, к которому у него нет прав, даже если это самый релевантный документ в компании.
Мы реализуем это фильтрацией на этапе поиска: каждому фрагменту присваивается набор групп доступа, и запрос выполняется только по разрешённому подмножеству. Такой подход надёжнее постфильтрации уже сгенерированного ответа, потому что закрытые данные вообще не попадают в контекст модели и не могут быть ею пересказаны.
Частые вопросы
Для общих вопросов — да, для рабочих решений — нет. Чат не знает ваших регламентов, лимитов и внутренних исключений, поэтому будет отвечать правдоподобно и неверно. RAG решает именно эту проблему: ответ формируется по вашим документам, и каждая рекомендация сопровождается ссылкой на источник, которую сотрудник может проверить за один клик.
Противоречия — это задача не модели, а владельца процесса. На этапе подготовки корпуса мы фиксируем конфликтующие версии документа и выносим их на согласование: какая редакция действует. Пока противоречие не разрешено, система помечает оба фрагмента как спорные и не принимает решение самостоятельно — это честнее, чем прятать проблему за уверенным ответом.
Качество скоринга измеряется на исторических данных: ROC AUC, precision и recall при выбранном пороге. Для задач оценки контрагентов на накопленной истории обычно достигается ROC AUC в диапазоне 0,75–0,88. Важно понимать, что модель не заменяет решение человека, а упорядочивает поток: она показывает, какие сделки стоит смотреть в первую очередь, и объясняет, какие признаки повлияли на оценку.
Мы настраиваем инкрементальное обновление индекса: новые и изменённые документы попадают в очередь обработки, старые версии переводятся в архив и перестают выдаваться в ответах. Владелец документа указывает срок действия, и система предупреждает, когда регламент устарел. Это снимает классическую проблему корпоративных баз знаний, где поиск уверенно цитирует документ пятилетней давности.
AI для бизнес-процессов: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Нужна система, которая находит нужный пункт регламента?
Покажите два-три документа и типовые вопросы сотрудников — соберём прототип поиска и покажем, как он отвечает на ваших данных.