Интеграция LlamaIndex для RAG и индексации данных

LlamaIndex: почему поиск по базе знаний выдаёт мусор

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

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

Вторая половина проблемы — источник ответа. Без метаданных (документ, редакция, дата, раздел) и порога релевантности в контекст попадают дубли и устаревшие версии; модель добросовестно пересказывает то, что получила, и на один вопрос выдаёт два противоречащих ответа. Проверить нечего — ссылки на фрагмент нет.

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

Что даёт управляемая индексация данных на практике

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

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

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

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

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

Режимы работы LlamaIndex: сравнение подходов

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

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

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

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

1. Аудит источников данных. Собираем, что есть: регламенты, база знаний, таблицы, сканы переписки. Фиксируем форматы, владельцев, частоту изменений и права доступа — от этого зависит, что можно индексировать, а что обязано остаться закрытым.
2. Схема индекса. На LlamaIndex описываем, на какие фрагменты бьётся документ и какие метаданные к ним приклеиваем: раздел, дата, роль пользователя. Крупный фрагмент размывает ответ, мелкий теряет контекст — размер подбираем замерами, а не на глаз.
3. Настройка поиска. Собираем гибридную выдачу: поиск по смыслу плюс поиск по точным формулировкам и артикулам, с переранжированием. Подбираем число фрагментов, уходящих в модель: больше — полнее ответ, но выше задержка.
4. Проверка на эталонных вопросах. Берём 50–100 реальных вопросов сотрудников с известными ответами и замеряем, попадает ли нужный источник в топ выдачи. Расхождения разбираем: обычно это ошибки разбивки или неучтённые синонимы.
5. Отказ и доступы. Проверяем, что система отвечает «в источниках нет данных», а не додумывает, и что сотрудник видит только разрешённые ему документы. Эти сценарии ломают доверие быстрее всего.
6. Передача решения. Отдаём конфигурации, схему индекса, регламент переиндексации и инструкцию для владельца базы знаний, показываем, как самим замерять качество после правок.

Артефакты интеграции LlamaIndex: что остаётся вам

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

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

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

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

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

Что изменили в индексации

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

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

Как измеряли результат

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

Доля ответов с нерелевантным источником упала с 38% до 12%, попадание в топ-3 выдачи выросло с 54% до 89%, а доля обращений, закрытых без эскалации на вторую линию, — с 61% до 84%. Подготовка ответа сократилась с шести минут до двух.

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

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

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

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

По точности попаданий выбор зависит от трафика: на однородных запросах без идентификаторов хватает векторной ветки, а на смешанных гибрид поднимает в топ-3 то, что чистый смысловой поиск терял.

Технические сомнения перед интеграцией LlamaIndex

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

Какой будет нагрузка на хранилище?

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

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

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

Как обеспечивается приватность данных?

Права доступа наследуются из источника: сотрудник видит в ответе только те фрагменты, к которым у него есть доступ. Запросы и ответы логируются, история остаётся у вас.

Сколько усилий требует сопровождение?

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

Расскажите о задаче — вернёмся с оценкой и планом

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

• Состав данных. Какие источники индексируем (файловые хранилища, база знаний, внутренние порталы, таблицы), в каких форматах, какой суммарный объём и как часто контент меняется. Отдельно — кто владелец каждого источника и через кого оформляются доступы.
• Сценарии запросов. 15-30 реальных формулировок от ваших сотрудников, включая те, где поиск сейчас даёт неверный результат. На них мы настраиваем разбиение документов на фрагменты и подбираем веса поиска.
• Требования к ответу. Нужна ли ссылка на первоисточник, допустимая задержка ответа, язык выдачи и что считается ошибкой: пропуск факта или уверенный неверный ответ.
• Контур размещения. Облако или закрытая инфраструктура, требования службы безопасности, разграничение прав по ролям — от этого зависит схема хранения индекса и режим доступа к модели.
• Текущие наработки. Чем уже пользуетесь для поиска и хранения векторов, есть ли прототипы на LlamaIndex — работающее не переписываем, встраиваем в новую схему.
• Критерии приёмки. Доля корректных ответов на тестовом наборе вопросов, время отклика, набор вопросов-провокаций, на которых проверяем устойчивость.
• Люди и сроки. Кто принимает решения со стороны заказчика, кто тестирует и к какой дате нужен рабочий контур.

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