Спросите любого, кто выпустил продукт на основе генерации с дополненной выборкой (RAG), что было самым сложным, и почти никто не скажет «модель». Модель — это простая кнопка. Сложная часть — это пайплайн вокруг неё: как вы разбиваете документы, каким эмбеддингам доверяете, как объединяете результаты поиска по ключевым словам и векторного поиска и как узнаёте, что вся система всё ещё работает после того, как клиент загрузил 300-страничный отсканированный PDF с таблицами. Именно этот разрыв между демо, которое отвечает на три вопроса, и производственным RAG-пайплайном, который отвечает на десять тысяч в день, и оправдывает существование курса «Построение RAG-систем» — но давайте сначала поговорим о реальной работе.
Почему качество поиска, а не качество генерации, определяет результат
RAG-система делает одну вещь: она помещает нужный текст перед моделью. Если извлечённые чанки не содержат ответа, лучшая в мире LLM либо сгаллюцинирует, либо скажет, что не знает. И то, и другое — сбои на уровне поиска, а не генерации. Вот почему команды, которые тратят недели на настройку промптов и дни на настройку чанкинга, обычно выпускают что-то, что всё ещё не справляется с теми же вопросами.
Механизм прост и беспощаден. Эмбеддинги сжимают смысл в вектор фиксированного размера. Чанкинг решает, какая единица смысла будет сжата. Если чанк состоит из 2000 токенов, один вектор теперь представляет пять разных идей, и поиск по сходству возвращает его для всех пяти — размывая точность. Если чанк состоит из 80 токенов, вы теряете контекст, и модель не может рассуждать между предложениями. Универсального размера чанка не существует; есть только размер, соответствующий вашим документам и вашим вопросам.
Разбор примера: исправление бота поддержки, который «знает всё и ничего»
Представьте ассистента поддержки для B2B SaaS, проиндексированного по 12 000 статей справочного центра и 4 000 внутренних PDF. Пользователи сообщают, что он хорошо отвечает на вопросы о ценах, но не справляется с вопросом «как мне перейти со старого API». Вот порядок действий, в котором на самом деле работает практик.
Шаг 1 — Воспроизведите с помощью трассировки поиска, а не журнала чата. Возьмите 50 реальных вопросов, на которых система даёт сбой, пропустите их только через поисковик и изучите, что вернулось. В данном случае руководство по миграции — это одна длинная статья с 40 подзаголовками. Фиксированный чанкинг по 512 токенов разрезал её посреди процедуры, поэтому поисковик вернул шаг 7 без шагов 1–6.
Шаг 2 — Измените стратегию чанкинга, прежде чем трогать модель. Переключитесь на чанкинг с учётом структуры: разбивайте по заголовкам, сохраняйте связи родитель-потомок, чтобы извлечённый дочерний чанк мог подтянуть свой родительский раздел для контекста. Одно это обычно восстанавливает большую долю сбоев на процедурном контенте.
Шаг 3 — Добавьте гибридный поиск. Векторный поиск плохо справляется с точными идентификаторами — кодами ошибок, именами API, строками версий. Добавьте BM25 рядом с плотным индексом и объедините с помощью reciprocal rank fusion (RRF), который комбинирует ранжированные списки по формуле 1/(k + rank) с k около 60. Запрос о миграции содержит «legacy API v1» — BM25 попадает точно, векторы — нет.
Шаг 4 — Переранжируйте топ-50 до 5. Кросс-энкодерный реранкер оценивает пары запрос-документ совместно, а не сравнивает независимые векторы. Это медленнее и дороже на запрос, но это самый большой прирост точности для большинства команд. Извлекайте широко, переранжируйте узко.
Шаг 5 — Измеряйте до и после. Создайте небольшой размеченный набор: 100–200 пар вопрос/ответ с отмеченным правильным исходным чанком. Отслеживайте recall@k (появился ли правильный чанк в топ-k?) и достоверность ответа. Без этого набора вы гадаете.
Где сама схема ломается
1. Документы меняются, и никто не переиндексирует. Страница с ценами обновляется; векторное хранилище всё ещё содержит старый чанк. Бот уверенно цитирует цену прошлого квартала. Заметьте это рано с помощью проверки актуальности: храните временную метку для каждого чанка и подавайте сигнал, когда хеш исходного документа меняется без соответствующего повторного эмбеддинга. Если уже слишком поздно, вам нужна задача переиндексации и способ аннулировать устаревшие ответы — а не правка промпта.
2. Модель эмбеддингов устаревает. Провайдеры выводят модели из эксплуатации. Ваш индекс был построен с одной версией; новые запросы эмбеддятся другой. Оценки сходства незаметно смещаются, и полнота падает без единой ошибки в логах. Смягчение: зафиксируйте версию модели, храните имя модели в метаданных индекса и планируйте бюджет на полную переэмбеддингизацию до того, как она понадобится.
3. Гибридный поиск помогает, пока не начинает вредить. Веса RRF по умолчанию фиксированы. Для корпуса, который на 90% состоит из естественного языка и на 10% из кода, BM25 может доминировать на коротких запросах и подтягивать шумные совпадения по ключевым словам. Следите за вкладом каждого поисковика по запросам; если один всегда побеждает, ваши веса слияния неверны.
4. Переранжирование выходит за бюджет задержки. Кросс-энкодер по 50 кандидатам может добавить сотни миллисекунд. Под нагрузкой тайм-ауты каскадно нарастают, и система откатывается к сырым векторным результатам — именно к тому качеству, от которого вы пытались уйти. Кэшируйте переранжированные результаты для повторяющихся запросов; следите за p95, а не за средним.
Пути обучения и их реальная стоимость
Самостоятельное обучение — самое дешёвое по деньгам и самое дорогое по времени. Статьи и блоги хорошо освещают чанкинг и RRF, но никто не расскажет вам о вашем конкретном режиме отказа — вам придётся самому строить оценочный набор и интерпретировать его в одиночку. Неверное решение здесь стоит переиндексации всего корпуса.
Практика на собственных документах — самый быстрый учитель, при условии, что у вас есть размеченный оценочный набор. Курсы сжимают цикл: они проходят через расчёты чанкинга и слияния с примерами и дают вам то, с чем можно сверять свои решения. «Построение RAG-систем» — один из таких путей: он охватывает чанкинг, эмбеддинги, векторные хранилища, гибридный поиск, переранжирование, Graph RAG и оценку с кэшированием и мониторингом.
| Путь | Время | Стоимость | Основной риск |
|---|---|---|---|
| Самостоятельное обучение | Недели-месяцы | Низкая | Нет обратной связи по вашим сбоям |
| Курс с наставником | Дни-недели | Умеренная | Всё равно нужны свои данные |
| Производственный опыт | Месяцы | Самая высокая | Дорогие ошибки |
Кому это подходит, а кому нет
Подходит инженерам, которые уже выпускают LLM-функции и теперь нуждаются в поиске, выдерживающем реальные запросы, и техническим руководителям, оценивающим, стоит ли векторная база данных или реранкер своих денег. Не подходит тем, кто ищет конструктор ассистентов без кода, или тем, кто не будет строить оценочный набор — без измерений любая техника — это догадки.
Курс проходит через эти расчёты с примерами и даёт обратную связь по вашим решениям — подробности и запись на странице Построение RAG-систем. Начните со своего собственного корпуса и одного вопроса, на котором система даёт сбой; именно там начинается настоящее обучение.
Начать можно здесь: RAG-системы с нуля.