AI-поиск по документации: RAG и семантический поиск

Семантический поиск по документации: где ломается

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

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

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

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

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

Что меняется после внедрения: время ответа и точность

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

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

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

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

Режимы индексации и выдачи: сравнение подходов

Схема выдачи определяет, что вообще попадёт в ответ: точные совпадения терминов, близкие по смыслу фрагменты или объединённый список. Это не выбор «лучше или хуже», а разные профили ошибок — и подбирать режим нужно под поток запросов, а не под модный термин.

Ключевое для внедрения: режимы совместимы между собой, а не взаимоисключающи. Оба индекса строятся из одного корпуса документов и живут параллельно, а способ выдачи переключается параметром сервиса — переиндексация при этом не нужна. Это позволяет вводить гибридную выдачу постепенно: сначала переранжирование включается на части запросов, выдача сравнивается с базовой на эталонном наборе, и любое изменение откатывается одним переключением.

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

Этапы внедрения: от аудита корпуса до передачи

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

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

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

Что передаём на руки: схемы, регламенты, доступы

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

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

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

Кейс: как выросли точность ответов и скорость выдачи

Кейс внедрения семантического поиска: логистический оператор Северный Путь хранит 40 000 страниц регламентов, инструкций по оборудованию и типовых договоров. Ответы искали вручную: сотрудник прогонял поиск по ключевым словам, открывал пять-десять файлов и всё равно уходил уточнять к автору документа. Клиент ждал ответ 20–40 минут, а часть формулировок сотрудники давали по памяти — без подтверждения первоисточником.

Метрики до и после

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

Контрольный набор и достоверность ответов

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

Чем векторный подбор отличается от подбора по словам?

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

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

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

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

Сомнения по качеству ответов и приватности данных

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

Второй источник сомнений — права доступа и качество разметки. Метка доступа наследуется от документа к каждому фрагменту и применяется на этапе поиска, а не после генерации: сотрудник физически не получит абзац, к которому у него нет прав. Насколько ровно документы разбиты на фрагменты, определяет попадание в выдачу — эту часть проверяем на эталонных вопросах до запуска.

Как права доступа применяются к фрагментам?

Права выставляются на уровне фрагмента, а не всего документа, — иначе закрытые разделы утекают в общую выдачу. Фильтр по доступам срабатывает до генерации, поэтому запрещённый кусок не попадает ни в ответ, ни в контекст модели. При изменении прав документ переиндексируется.

Можно ли развернуть поиск в закрытом контуре?

Да: индексация, хранение и генерация работают на ваших мощностях, без обращений к внешним сервисам. Документы не покидают контур, вход в систему — через вашу корпоративную авторизацию, а логи запросов остаются под вашим контролем.

Обсудим задачу: подготовим оценку и план работ

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

В ответ на описание задачи присылаем оценку и план: схему поиска, состав этапов, точки проверки. В план сразу закладываем метрики качества и способ их замера на вашем корпусе.

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

Опишите задачу — что за документы, кто ищет и какой результат считаете неудачей — и мы вернёмся с оценкой, схемой и планом внедрения.