Встроенная RAG/база знаний для бизнес-документов

RAG полезен, когда корпус больше разумного контекста, документы часто меняются или ответ должен опираться на найденные фрагменты. Если есть один короткий неизменный файл, сначала стоит проверить прямую передачу контекста: архитектура будет проще. Решение принимают по контрольному набору вопросов, полноте ответа, стоимости и времени обновления, а не по модности термина. Retrieval не исправляет плохие документы и не гарантирует отсутствие галлюцинаций.

Встроенный модуль TokenTool предназначен для продуктового сценария базы знаний внутри платформы. Страница не описывает публичный API для embeddings, rerank или управления векторами. Если интегратору нужен полностью внешний retrieval-контур, его проектируют отдельно и связывают с документированным генеративным API только после контролируемого теста. Нельзя предполагать поддержку endpoint'ов, которых нет в опубликованном контракте.

Корпус начинают с реестра источников: название, владелец, версия, дата обновления, правовое основание и аудитория. Дубли, черновики и отменённые регламенты помечают до загрузки. Если один вопрос имеет несколько противоречивых ответов, retrieval лишь быстрее найдёт конфликт. Владелец данных должен решить, какой источник главный и как обрабатываются исключения. Поэтому наличие владельца — блокирующий критерий scorecard.

Документы разбивают по смысловым границам, сохраняя заголовок, раздел и источник. Универсальный размер фрагмента нельзя обещать: он зависит от структуры, языка и вопросов. Для таблиц, сканов и сложной вёрстки требуется отдельная проверка извлечения. Фраза «поддерживается любой формат» была бы неверной. Пилот начинает с небольшого контролируемого набора, в котором можно вручную проверить каждую ссылку на источник.

База знаний часто содержит документы с разными аудиториями. До пилота определяют, какие группы могут задавать вопросы по каждому набору и где проверяется право. Логический проект TokenTool сам по себе не является обещанием RBAC или tenant isolation. Если доступ зависит от сотрудника, клиента или отдела, контроль реализуют в приложении и проверяют отрицательными тестами: пользователь без права не должен получить ни ответ, ни фрагмент, ни косвенное подтверждение существования документа.

В scorecard правило доступа сделано блокирующим. Это не означает автоматическую сертификацию после установки галочки; инструмент лишь показывает, что вопрос нельзя отложить. Интегратор документирует роли, источник истины для прав, поведение при ошибке и порядок отзыва. Секреты и персональные данные не копируют в публичные тесты, маркетинговые события или примеры. Для чувствительного корпуса отдельно согласуют хранение и сроки удаления.

До настройки retrieval составляют вопросы разных типов: точный факт, сравнение двух разделов, исключение, отсутствие ответа и устаревшая формулировка. Для каждого фиксируют допустимый ответ, обязательный источник и условие отказа. Набор должен отражать реальные задачи, но не содержать личных данных в экспортируемых отчётах. Десять удобных вопросов, подобранных после просмотра результата, не заменяют заранее замороженный тест.

Оценивают отдельно поиск и формирование ответа. Если нужный фрагмент не найден, проблема в корпусе, разбиении или retrieval. Если найден, но ответ исказил смысл, проверяют инструкцию и модель. Такой разбор не позволяет маскировать слабый поиск красивым текстом. Нулевая галлюцинация не обещается: безопасный контур должен уметь честно отказать, показать источник и отправить спорный случай на ручную проверку.

База без расписания обновлений быстро становится архивом. Для каждого источника назначают частоту проверки и событие, которое требует внеплановой загрузки: новый регламент, смена тарифа, отмена инструкции. После обновления повторяют затронутые эталонные вопросы и убеждаются, что старый фрагмент больше не влияет на ответ. Владелец подтверждает публикацию, а не просто перемещает файл в папку.

Полезно различать дату документа, дату загрузки и дату последней проверки. Они отвечают на разные вопросы. Если актуальность нельзя определить, ассистент должен сообщать ограничение и направлять к владельцу, а не уверенно комбинировать версии. TokenTool не гарантирует корректность исходных материалов; модуль помогает работать с загруженной базой, а качество и права остаются частью процесса интегратора.

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

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

Контрольный прогон выполняют на фиксированной версии корпуса, конфигурации и списка вопросов. Для каждого вопроса сохраняют только необходимые признаки: найден ли обязательный источник, подтверждён ли ответ экспертом, корректен ли отказ и сколько времени заняла обработка. Если в процессе меняют документ, разбиение или инструкцию, это новая версия теста. Смешивать результаты до и после изменения нельзя.

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

После достижения целевого качества проводят отрицательные проверки. Вопрос без ответа должен приводить к понятному отказу, пользователь без права — не получать закрытый фрагмент, удалённый документ — перестать влиять на результат после обновления. Отдельно проверяют, что журналы и экспорт не содержат секретов или лишних персональных данных. Только совокупность положительных и отрицательных тестов позволяет обсуждать расширение корпуса. Итог подписывает владелец данных, а не только разработчик retrieval-контура. Спорные ответы сохраняют как новые регрессионные примеры без реальных секретов и реквизитов клиентов. Версию теста указывают в каждом итоговом протоколе.