RAG Python на первом шаге стоит делать как самый маленький работающий прототип: десяток документов, поиск по ним, ответ с цитатой и короткий тест, который показывает, где система ошибается. Архитектурные схемы и выбор базы приходят позже. Сначала нужна проверка простого вопроса: находит ли поиск нужный абзац и цитирует ли ответ именно его, вместо пересказа общих знаний модели.
Состав прототипа
Прототип состоит из пяти деталей: загрузка документов, разбиение на фрагменты, векторы, хранилище и ответ с цитатой. Каждую можно заменить позже, поэтому на старте берите самое простое.
По документации LangChain, типовой конвейер поиска складывается из загрузчиков документов, разделителей текста, моделей эмбеддингов, векторных хранилищ и ретриверов. Для простого случая подходит схема из двух шагов: сначала всегда поиск, затем генерация ответа по найденному. Она предсказуема и легко проверяется, в отличие от варианта, где модель сама решает, когда искать.
Выберите один язык документов и один язык вопросов. Многоязычные корпуса требуют отдельного разговора о моделях эмбеддингов, и на первом прототипе они только запутывают картину. Если ваши документы русскоязычные, проверьте, как выбранная модель справляется именно с русским: сделайте пару пробных поисков и посмотрите, что возвращается.
| Деталь | Что делает | Чем заменить позже |
|---|---|---|
| Загрузчик | Читает файлы и отдаёт текст с названием источника | Подключение к вики, диску, трекеру |
| Разделитель | Режет текст на фрагменты по смыслу | Разбиение по заголовкам и таблицам |
| Эмбеддинги | Превращают фрагменты в векторы | Другая модель, подходящая языку |
| Хранилище | Держит векторы и тексты | Отдельная векторная база |
| Ответ | Собирает вопрос и найденное, просит цитату | Повторная сортировка, гибридный поиск |
Общую картину, из чего вырастает рабочая система в компании, мы разбирали в статье RAG: как устроена система. Здесь только минимум, который помещается в один файл и один вечер.
Корпус и разбиение
Первый корпус держите небольшим и знакомым: те документы, о которых вы сами можете сказать, где лежит ответ. Тогда любую ошибку поиска вы заметите глазами, без сложных метрик.
- Берите один тип документов: регламенты, инструкции или описания продуктов, без смеси из всего подряд.
- К каждому файлу сохраняйте название и дату, они потребуются для цитаты.
- Удалите повторы и устаревшие версии до загрузки, иначе поиск вернёт противоречивые ответы.
- Резать текст лучше по абзацам и заголовкам, чем по фиксированной длине: смысловая единица остаётся целой.
- Небольшое перекрытие соседних фрагментов спасает ответы, которые лежат на границе.
Хранилище на старте может жить в памяти процесса: переносимость и скорость на этом этапе вторичны, главное быстро запускать эксперименты и сравнивать результаты. Постоянная база понадобится, когда корпус вырастет или к системе подключатся коллеги. Размер фрагмента подбирается опытом: слишком мелкие куски теряют контекст, слишком крупные размывают смысл и забивают запрос лишним текстом. Начните со средней величины, посмотрите на десятке вопросов, что возвращает поиск, и меняйте величину ступенями, фиксируя результат каждого запуска. Так зависимость видна на цифрах прогона, и угадывать нечего.
Подробный разбор подготовки данных для рабочей системы вынесен в отдельный материал RAG данные: подготовка корпуса и обновление, а проверка качества самого поиска разобрана в статье RAG поиск: оценка релевантности. В прототипе достаточно аккуратной загрузки.
Ответ с цитатой
Главное требование к прототипу: каждое утверждение в ответе подкреплено фрагментом, который можно открыть и прочитать. Без цитаты RAG превращается в чат с красивым оформлением.
- Вопрос пользователя превращается в вектор той же моделью, что использовалась для фрагментов.
- Хранилище возвращает несколько ближайших фрагментов вместе с названиями источников.
- В запрос к модели помещаются вопрос, найденные фрагменты и правило: отвечать только по ним.
- Правило требует цитату: название источника и короткая выдержка рядом с каждым утверждением.
- Если подходящих фрагментов нет, ответом служит прямая фраза, что в документах ответа найти нельзя.
- Код возвращает пользователю ответ и список использованных фрагментов отдельно, чтобы их было видно.
Формат вывода тоже стоит продумать. Ответ с цитатой удобнее читать, когда источник указан в конце абзаца, а выдержка из документа показана отдельным блоком. Пользователь тогда проверяет утверждение за секунды: открывает источник и сверяет текст. Если проверка требует усилий, ею перестают заниматься, и польза от цитат исчезает.
Пятый шаг критичен. Модель склонна отвечать, даже когда подсказок нет, поэтому разрешение признать отсутствие ответа записывается явно, а потом проверяется тестом.
Какие документы вашей компании подошли бы для первого пробного корпуса?
Проверка ответов
Тест для прототипа можно собрать за полчаса. Нужен список вопросов, на каждый из которых вы знаете правильный ответ и документ, где он лежит.
- Вопросы с ответом в одном документе: проверяют, находит ли поиск нужный абзац.
- Вопросы, ответ на которые рассредоточен по двум документам: показывают, хватает ли числа найденных фрагментов.
- Вопросы без ответа в корпусе: система обязана признать отсутствие вместо выдумки.
- Вопросы с устаревшим ответом: проверяют, всплывает ли старая версия документа.
- Перефразированные вопросы: убеждают, что поиск понимает смысл, а совпадение слов вторично.
Прогоняйте тест после каждого изменения: смены размера фрагмента, другой модели, другого числа возвращаемых фрагментов. Результаты складывайте в одну таблицу по датам. Через пару недель такая таблица покажет, какие изменения помогали, а какие вредили, и избавит от споров на уровне ощущений.
Для каждого вопроса записывайте три факта: найден ли нужный фрагмент, верен ли ответ, есть ли цитата. Три колонки в таблице покажут, где ломается цепочка: на поиске, на ответе или на оформлении цитаты. Это направляет доработку точнее, чем общее впечатление.
Границы прототипа
Прототип отвечает на вопрос «работает ли идея на наших документах». Про доступы, нагрузку, скорость и безопасность он молчит. Эти вопросы встают на следующем этапе, и откладывать их нужно сознательно.
К прототипу подключаются только документы без персональных данных и коммерческих секретов, либо ответ строится на своём сервере. Права доступа к документам проверяются отдельно, до того как систему увидят коллеги.
Заведите заметку «что мы узнали»: какие вопросы вызвали ошибки, какие документы оказались проблемными, какие правила в запросе помогли. Она станет основой для технического задания на рабочую систему и сэкономит неделю обсуждений. Покажите заметку тем, кто будет пользоваться системой, и соберите их вопросы: реальные формулировки сотрудников почти всегда отличаются от тех, которые придумывает разработчик, и именно на них нужно проверять поиск.
Следующие шаги зависят от результата теста. Если поиск слаб, подумайте о повторной сортировке и гибридном поиске. Если нужна постоянная база, смотрите статью Qdrant в Docker: хранение индекса и обновление. Если результат смешанный, вернитесь к данным: чаще всего причина кроется в качестве документов, а выбор модели вторичен. Один хороший абзац в инструкции даёт больше, чем смена векторной базы. Когда результат устраивает, начинается следующий этап: данные, права, оценка поиска и наблюдение за качеством. Как он выглядит в компании, показывает страница про нейросети для документов.