Собираем ИИ-агента, часть 9

В прошлый раз мы закончили с базой: выбрали оболочку, LLM и движок. Для агента этого маловато. Нужны ещё всякие интересные штуки вроде серверов MCP, A2A, скиллов, тулзов… Но сначала я хочу показать, как собрать RAG-конвейер, чтобы наше детище могло эффективно работать с базой знаний?

Под базой знаний я подразумеваю совокупность всех источников информации, доступных агенту, кроме веб-поиска. Это не только локальные документы, но также файлы на Google Диск, корпоративные БД, статьи в Confluence и Notion.

Я уже писал о том, что у топовых LLM контекст номинально составляет 1 миллион токенов и больше. Так-то 5-8 средних книг. Проблема в том, что после 128-256к токенов начинается деградация – модель забывает, что прочла вначале, или в середине, игнорирует инструкции?

Решение – подключить поиск по базе знаний. Но не только лексический (как в SEO), а ещё и смысловой (как рекомендации в YouTube или TikTok). Такой поиск, сочетающий оба подхода, называется гибридным. Именно эту задачу решает RAG-конвейер, которого нет ни у чат-бота, ни у вендорской агентной среды. Но кастомному агенту его запилить – приключение на 15 минут, зашли и вышли…?

Что такое RAG-конвейер

RAG (Retrieval-Augmented Generation) – это когда в контекст помимо промптов подливается дополнительная информация. Не вся подряд, а только релевантная запросу, самый сок.

В зависимости от контекста, под термином RAG сегодня может подразумеваться поисковый пайплайн практически любого вида, от простеньких комбинаций вроде SQLite + FTS5 + BM25 до мощных RAGFlow с каскадом реранкеров. Сейчас важно запомнить суть концепции: LLM ничего не ищет сама. За неё это делают другие, специально обученные нейросети. А ещё – математические алгоритмы.

Здесь и дальше, говоря о RAG, я будут иметь ввиду гибридный конвейер, сочетающий два вида поиска – лексический и семантический (он же – векторный, или dense). Это самый сложный вид RAG-конвейера, эффективность которого прямо пропорциональна объёмам базы знаний, к которой он подключён.

То есть чем больше и разношёрстнее ваша документация (как по форматам, так и по источникам данных), тем гибридный RAG-конвейер эффективнее.

Как это работает

База знаний заранее индексируется и «режется» на куски – их называют чанками. Потом эти чанки векторизуются, то есть дублируются в векторную БД в виде числовых последовательностей. И когда пользователь делает запрос к агенту, тот выполняет два вида поиска – лексический по индексу (ищет совпадения по словам) и семантический по векторной БД (ищет совпадения по смыслу).

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

Типовой RAG-конвейер состоит из:

поискового движка и алгоритма лексического поиска (например, FTS5 и BM25);

модели эмбеддингов (например, Qwen3-embedding-8b);

СУБД и векторной БД (например, SQLite и ChromaBD);

модели реранжирования (например, Qwen3-reranker-4b).

Модель эмбеддингов чаще называют просто эмбеддером, а модель реранжирования – реранкером. «Бесплатная» альтернатива реранкеру – алгоритм слияния/реранжирования (например, RRF).

По теории всё. Со следующего поста будем собирать свой RAG-конвейер?

#ai_necromancer #иигайды

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: