Backend Meetup от OneTwoTrip: RAG — умный поиск для базы знаний
18 сентября 2025 прошёл наш офлайн-митап для бэкендеров. В этой статье — презентация Кирилла Красавина, который рассказал про систему для умного поиска по базам знаний, а ещё поделился своим опытом вайбкодинга.
Выступление Кирилла
О спикере
Кирилл Красавин — teamlead в команде «Платформа» OneTwoTrip. Занимается инфраструктурными сервисами: авторизация, оплата, отправка уведомлений и прочее. А общий опыт разработки у Кирилла более 10 лет.
Идея прикрутить векторный поиск к Confluence родилась у Кирилла при поиске информации в базе знаний с помощью встроенного полнотекстового поиска — это не так просто, если точно не знать, какие ключевые слова вбивать в него. От самой идеи до работающего прототипа прошла всего пара вечеров — и вот мы здесь, готовы рассказать вам, как сделать так же.
Что такое RAG-система
RAG-система, или Retrieval-Augmented Generation — в вольном переводе это поисковая (retrieval) дополненная релевантным контекстом (augmented) генерация ответа пользователю (generation).
Отметим, что в данном случае используется языковая модель (LLM), которая при дополнении эмбеддингами и векторным поиском использует релевантный контекст. Благодаря этому повышается точность и полнота генерируемых ответов.
Сравнение подходов
Для поиска информации в базе знаний есть несколько различных вариантов:
- Встроенный поиск в Confluence — полнотекстовый поиск по ключевым словам, вполне рабочий инструмент.
- Базовая модель LLM + MCP-сервер — позволяет обогащать контекст LLM.
- Fine-tuned модель — вы можете заранее обучить LLM, чтобы она отвечала на основе данных Базы знаний.
- RAG-система (о ней будет весь доклад).
Схему работы обычного встроенного поиска можно посмотреть на 02:52. С ним в целом всё понятно: он не очень умный и воспринимает только ключевые слова. Если же вбить в поиск вопрос или целую фразу, например, «как запустить новый сервер?», вряд ли он ответит вам что-то внятное (если нет статьи, содержащей точно такой набор слов).
Про LLM + MCP-сервер Кирилл рассказывает с 03:10. В момент, когда вы задаёте вопрос LLM, она может решить, что ей нужна дополнительная информация, и обогатить контекст с помощью Базы знаний.
На 03:40 представлена схема LLM + Fine tuning. Это интересный вариант, но для скорости разработки и внедрения прототипа мы выбрали RAG-систему (схема её работы с 03:58). Она по сути хранит заранее проиндексированные данные из статей вашей базы знаний и запускает векторный поиск, а после передаёт результаты в LLM для генерации ответа.
Преимущества RAG
По сравнению с альтернативными вариантами у RAG-системы целый ряд преимуществ.
- Актуальность данных: статьи базы знаний можно регулярно переиндексировать, это довольно быстрый процесс.
- Меньше галлюцинаций LLM: используется актуальный и при этом ограниченный контекст.
- Проверяемость: всегда можно посмотреть, на основе каких данных сгенерирован ответ.
Небольшой глоссарий
Разберём несколько терминов, которые будут встречаться дальше.
Эмбеддинг, или вектор — по сути, это массив с числами, который представляет из себя фрагмент (отпечаток) данных, например, кусочек вашей статьи, который перевели в вектор.
Векторный поиск — инструмент, с помощью которого можно находить похожие по смыслу вектора.
Индексация — в контексте доклада это процесс, при котором, с помощью специальной эмбеддинг-модели (об этом дальше), создаются векторы для статей в базе знаний.
Архитектура прототипа
Переходим к процессу — и сразу на 6:48 смотрим, как работает индексация. Сперва нам надо скачать все статьи из Confluence и разбить их на чанки, или небольшие смысловые фрагменты текста. Почему так? Эмбеддинг-модели работают с ограниченным числом токенов и теряют точность на слишком длинных текстах. Поэтому мы делим статьи на части, чтобы корректно создать векторы и повысить точность последующего поиска. Затем каждый чанк преобразуется в вектор и сохраняется вместе со своим текстом в базе данных.
После этого можно приступать к поиску (07:43). Как он работает? Вопрос, который задаёт пользователь, с помощью той же эмбеддинг-модели преобразуется в вектор, и после этого ваша СУБД может найти похожие по смыслу векторы, достать их с фрагментами статей и передать LLM — и та сгенерирует на их основе ответ.
Пишем прототип
Прототип Кирилл решил написать, потому что хотел попробовать полностью агентскую разработку с нуля, то есть сам руками код не писал (о вайбкодинге дальше).
Архитектуру прототипа можно посмотреть на 08:25. В ней есть клиентская часть (поисковая строка и результаты выдачи) и API-сервер, который связан с API Confluence и Gemini, а также собственной базой данных, где хранится результат. Про выбор API-сервера смотрите на 09:15 (выбор без выбора, так как в OneTwoTrip исторически много JS), а про выбор СУБД — на 09:35. Для векторного поиска использовали PostgreSQL + pgvector (слайд на 10:01). А о выборе эмбеддинг-модели и сравнении различных вариантов смотрите и слушайте с 11:11.
Более подробные схемы сценариев работы API-сервера и поиска можно увидеть с 12:30.
Выводы
Что именно, по опыту Кирилла, влияет на качество поиска:
- Качество и актуальность базы знаний. Если у вас подробные статьи, разбитые на абзацы, с использованием заголовков и подзаголовков, поиск будет лучше.
- То, насколько хорошо вы разбили данные на чанки (логически завершённые фрагменты, связи).
- Выбранная модель, её размерность и тюнинг.
- Ранжирование.
- Качество промпта с контекстом в LLM.
Сценарии использования RAG
Вот как ещё можно использовать эту систему:
- Помощь для оператора или бота поддержки, исходя из вопроса пользователя.
- Помощь разработчикам для поиска контракта фронтенда и бэкенда (проиндексировать swagger).
- Поиск процессных знаний: как оформить задачу.
- Онбординг.
- Замена API базы знаний в MCP серверах.
Бонус: опыт вайбкодинга
Вайбкодинг (от англ. vibe coding) — это подход к программированию, при котором код по описанию задачи генерирует ИИ, а человек только формулирует идею и механику.
Вот какие инструменты использовал Кирилл:
- Gemini 2.5 Pro — для проработки альтернатив, выбора инструментов и архитектуры решения, а также для поиска информации.
- Copilot + Claude Sonnet 4 — агентский режим с планированием реализации решений и фиксацией результатов в md-файлах.
И вот какие советы Кирилл может дать тем, кто тоже хочет попробовать повайбкодить:
- Составьте хорошую контекстную документацию в вашем проекте, чтобы агент понимал, как перезапустить сервер, прогнать тесты и прочие сервисные команды.
- Подготовьте план изменений перед реализацией — агентские системы сразу переходят к реализации, но лучше их немного притормозить и попросить сперва написать план.
- Помните, что окно контекста агента ограничено, поэтому они могут забывать что-то из начала переписки.
- Фиксируйте изменения в плане поэтапно.
- Не шутите с миграциями!