Разработка RAG с векторной базой данных Weaviate

RAG Weaviate: почему поиск не находит нужный ответ

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

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

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

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

Что даёт управляемый поиск: скорость ответа и полнота выдачи

Первый эффект — время до ответа. Гибридный поиск в Weaviate объединяет совпадение по терминам и близость по смыслу, поэтому выдача не зависит от того, угадал ли пользователь формулировку. На прогретом индексе ответ собирается за секунды вместо минут ручного поиска по папкам, чатам и почте.

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

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

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

Режимы RAG Weaviate: векторный, гибридный, с переранжированием

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

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

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

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

1. Аудит корпуса документов — инвентаризация источников: форматы, владельцы, срок актуальности, права доступа. Отдельно помечаем дубликаты и устаревшие редакции.
2. Разметка контрольной выборки вопросов — 100–200 реальных вопросов с верными ответами и указанием документа-источника. Она же становится тестом приёмки.
3. Схема хранения — структура индекса в Weaviate, размер фрагмента и перекрытие, поля для фильтрации по отделам, датам и правам доступа.
4. Настройка индексации базы знаний — распознавание сканов, нарезка на фрагменты, расчёт векторов, догрузка только изменённых документов по расписанию.
5. Проверка на контрольной выборке — доля ответов с верной ссылкой на источник и доля корректных отказов, когда данных в корпусе нет. Порог согласуем заранее.
6. Внедрение поиска в рабочий контур — доступы на уровне фрагментов, журнал запросов и источников, передача регламентов и обучение команды обновлять корпус без нас.

Комплект передачи: конфигурации, схемы доступа, регламенты

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

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

Комплект остаётся у вас в виде файлов в репозитории, а не в переписке. Опишите задачу — вернёмся с оценкой и планом, включая состав такого комплекта под ваш контур.

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

Точка старта

База знаний службы поддержки — несколько тысяч документов: регламенты, инструкции, разборы инцидентов. Оператор искал по ключевым словам и вручную листал выдачу, потому что формулировка клиента почти никогда не совпадала с формулировкой в регламенте. На размеченной выборке реальных обращений доля корректных попаданий в целевой документ держалась около 40%, а поиск ответа занимал 4–6 минут — часть обращений к этому моменту уже уходила на вторую линию.

Что изменили

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

Через месяц после выката точность попадания в нужный документ выросла с ~40% до 85%, время поиска ответа упало до 40–50 секунд вместе с чтением найденного фрагмента. Доля обращений, которые оператор закрывал сам, без передачи на вторую линию, поднялась с 55% до 80%.

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

Что делать, если поиск уже работает на другом решении?

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

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

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

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

Технические сомнения: нарезка, доступ, обновления индекса

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

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

Что делать с таблицами и сканами в документах?

Таблицу храним отдельным фрагментом вместе с заголовками строк и столбцов — иначе числа теряют смысл. Сканы распознаём и проверяем на контрольных страницах: без этого часть корпуса не находится.

Как часто обновлять индекс?

Инкрементально: сравниваем хэш документа и переиндексируем только изменённое, полная сборка — при смене параметров. Удалённый документ убираем из индекса, иначе ответ идёт по устаревшей версии.

Как разграничить права доступа к данным?

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

Как понять, что решение стало лучше или хуже?

Контрольный набор вопросов с эталонными ответами и источниками прогоняем при каждом изменении параметров. Смотрим долю попаданий в нужный фрагмент и полноту ответа — регресс видно до выкладки.

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

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

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

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