ИИ ИИшка Про
Обзоры
С

Поиск по рабочим документам: SQLite FTS5 или векторная база для ИИ-ответов

Редакция ИИШКА Про

Когда команда собирает внутреннюю базу знаний с ИИ-ответами, разговор быстро доходит до «нужна ли векторная база». Часто вопрос поставлен слишком рано. Сначала нужно узнать, какие запросы сотрудники задают на самом деле: ищут номер договора, точную формулировку пункта или описывают проблему своими словами. Для первых двух задач обычный полнотекстовый поиск нередко оказывается понятнее; для третьей поиск по смысловой близости может помочь. Разберём SQLite FTS5 и векторный индекс на одинаковом примере, не объявляя победителя без измерений.

Исходная задача

Представим 400 инструкций сервисной компании: гарантийные условия, маршруты возврата, шаблоны ответов и внутренние чек-листы. Сотрудник спрашивает: «Где описана замена устройства с повреждённой коробкой?» В документах это может называться «нарушена упаковка при приёмке». Другой сотрудник вводит точный номер формы «А-17». Руководителю важно не только получить ответ, но и открыть фрагмент-источник, увидеть дату его действия и понять, какая версия документа использована.

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

SQLite FTS5: сильная сторона — слова

FTS5 — модуль полнотекстового поиска SQLite. Он строит индекс слов и позволяет быстро находить документы по встречающимся выражениям. Это удобная основа для небольшого контролируемого архива: данные лежат в локальной базе, можно связать найденный фрагмент с идентификатором документа, датой и правами доступа. Поиск по номеру формы, названию детали или точной цитате обычно естественен. Сотрудник видит совпавшее место, а редактор может объяснить, почему документ оказался в выдаче.

Ограничение тоже понятно. Синонимы, опечатки и разные формы слова требуют настройки токенизации, словаря либо дополнительной логики. Русский язык особенно чувствителен к этому: вопрос «сломался экран» может не совпасть с формулировкой «повреждение дисплейного модуля». Можно расширять запрос или добавлять тематические метки, но тогда нужен контроль качества редактора. Не следует ожидать, что простая установка FTS5 автоматически даст поиск по смыслу.

Векторный поиск: сильная сторона — перефразирование

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

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

Сравнение на контрольных вопросах

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

При 400 документах разумно начать с FTS5 как базовой линии и добавить векторный слой только для типов вопросов, где он выигрывает на контрольной выборке. Ещё один вариант — гибрид: сначала находить кандидатов обоими способами, затем ранжировать и обязательно показывать ссылку на конкретный фрагмент. Но гибрид повышает сложность и не отменяет проверки версии документа. Если задача — просто поиск по точным названиям и артикулам, развернуть ради неё отдельную векторную инфраструктуру обычно избыточно.

Роль ИИ в ответе

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

Что выбрать

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

Частые вопросы

FTS5 понимает смысл запроса?

Нет, это полнотекстовый поиск. Его можно улучшить метками и обработкой слов, но он не становится эмбеддинг-моделью.

Векторная база гарантирует верную цитату?

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

Можно ли использовать оба метода вместе?

Да, если тесты показывают пользу гибрида. Но объединение индексов усложняет обновление, ранжирование и диагностику ошибок.

Какой тест провести до внедрения?

Соберите реальные вопросы с заранее подтверждёнными документами, выделите самые рискованные случаи и сравните качество выдачи, задержку и стоимость поддержки после изменения файлов.

Обзоры CSV или Parquet для отчёта после ИИ: что удобнее проверять и хранить CSV легко открыть глазами, Parquet лучше сохраняет типы и читает нужные столбцы. Сравниваем на задаче проверки отчёта, который помогла собрать нейросеть. Обзоры DuckDB для локального аудита ИИ-выгрузки: пять запросов до отчёта Показываем, как проверить строки, дубликаты, пропуски и суммы в CSV без отправки всего файла в чат. И где SQL-проверка не заменяет смысловую. Обзоры OpenRefine для очистки выгрузки после ИИ: локальная проверка без нового облачного сервиса Разбираем, как в OpenRefine найти разные написания одного значения, сохранить цепочку исправлений и не отправить конфиденциальную таблицу во внешний сервис. Обзоры text-to-cad: как проверить 3D-деталь, созданную по описанию, до печати Плагин превращает текстовое задание в CAD-файл, но пригодность детали решают размеры, допуски и проверка сетки. Разбираем безопасный пробный маршрут.
Опубликовано: 12 октября 16:35
← На главную