Урок 10 · Блок 2: ассистент по базе знаний · ~12 минут
Анатомия RAG-конвейера: от документа до ответа
⌂ Все уроки · Актуально на 10 июня 2026 · источники — в тексте · термины — в глоссарии · фундамент — урок 4
Главная мысль урока: RAG — это не один конвейер, а два. Первый готовит базу знаний (индексация), второй отвечает на вопросы. Понимая оба и зная семь мест, где они ломаются, вы сможете читать любое предложение разработчика как карту — и видеть, какие участки он забыл. Этим блок 2 и займётся: урок за уроком пройдём каждый участок.
Сначала фильтр: а нужен ли вам RAG вообще?
Прежде чем строить конвейер — проверка из дерева выбора урока 4, теперь с конкретным числом. Anthropic называет порог: если база знаний меньше ~200 тысяч токенов — это примерно 500 страниц текста — RAG не нужен. Кладите всё в промпт целиком.
Чтобы это не разоряло, есть кэширование промпта (prompt caching): провайдер запоминает уже обработанное начало запроса и не пересчитывает его заново при следующих обращениях. Повторные запросы становятся быстрее в 2 раза и дешевле до 90%. (Anthropic, Contextual Retrieval, сент. 2024)
Это первый вопрос приёмки любого RAG-предложения: «сколько страниц в нашей базе?» Если меньше пятисот — возможно, вам только что предложили построить завод ради одной табуретки.
Второй вопрос фильтра — «сколько запросов в день и кто спрашивает?» База больше порога, но спрашивает своя команда десяток раз в день? Тогда дешевле агентный поиск по файлам — без конвейера вообще (урок 15). RAG из этого блока — для третьего случая: запросов много, спрашивают клиенты, ответ нужен за секунды. Полное дерево — в справочнике «Дерево выбора».
Конвейер 1 · Индексация: готовим библиотеку
Этот конвейер работает до всяких вопросов — он превращает ваши документы в библиотеку с каталогом. Запускается при создании базы и потом при обновлениях.
документы → парсинг → нарезка на чанки → обогащение контекстом → точки на карте смыслов → хранилище
Парсинг — извлечение текста из PDF, презентаций, таблиц. Самый недооценённый этап: здесь портится больше всего (урок 11).
Нарезка — деление на чанки, кусочки по одной мысли (урок 4, теперь в деталях — урок 11).
Обогащение — к каждому чанку дописывается контекст, из какого он документа и о чём (урок 11).
Карта и хранилище — эмбеддинги и векторная база, знакомые по уроку 4.
Конвейер 2 · Ответ: работаем с читателем
Этот конвейер запускается на каждый вопрос пользователя — и оплачивается каждый раз.
вопрос → гибридный поиск (топ-50 кандидатов) → реранкер (топ-5 лучших) → модель пишет ответ с цитатами
Реранкер — «второй читатель» отбирает действительно отвечающие (урок 12).
Генерация — модель пишет ответ, опираясь на найденное и цитируя источники (урок 13).
🔬 Под капотом: почему конвейера именно два
Индексация — тяжёлая и медленная работа: распарсить сотни документов, нарезать, посчитать точки. Делать её при каждом вопросе невозможно — ответ нужен за секунды. Поэтому всю тяжесть выносят «за скобки» и делают заранее.
Отсюда два следствия для денег. Первое: индексация оплачивается один раз, ответы — постоянно, и это разные статьи бюджета (урок 14). Второе: всё, что меняет правила индексации — другая нарезка, другая эмбеддинг-модель, — заставляет пересчитать всю библиотеку заново. Это главный скрытый расход RAG-проектов.
Ответа вообще нет в базе — а система отвечает, будто есть.
Нужный документ есть, но не попал в топ выдачи поиска.
Попал в выдачу, но не вошёл в контекст модели (не хватило места).
Группа «нашли, но ответ плохой»:
Модель не сумела извлечь ответ из найденного текста.
Ответ не в том формате (просили таблицу — получили эссе).
Ответ неточный: близко, но мимо.
Ответ неполный: половина правды.
Заметьте: только три из семи лечатся «лучшей моделью». Остальные — это качество базы, нарезки и поиска, то есть инженерная работа над конвейером.
И главный вывод той же работы: по-настоящему проверить RAG-систему можно только в эксплуатации. Реальные вопросы пользователей всегда отличаются от тестовых. Запуск — не конец проекта, а начало его настройки.
Зачем это вам как заказчику
Первый вопрос — «сколько у нас страниц?» До ~500 — обсуждайте длинный контекст с кэшированием, а не RAG. Второй — «сколько запросов в день?» Десяток внутренних — обсуждайте агентный поиск (урок 15).
Просите нарисовать карту: «что у нас на конвейере индексации, что на конвейере ответа?» Дыры видны сразу.
В договоре должна быть строка про после запуска: логи, разбор ошибок, ежемесячная донастройка. «Сдал и забыл» с RAG не работает.
Проверьте себя
Повторение блока 1. База знаний школы — 80 страниц FAQ и условий, меняется раз в месяц. Разработчик предлагает RAG с векторной базой. Что ответите?
Верно! 80 страниц « 500 — вся база влезает в промпт, кэширование делает это дёшево. RAG здесь — завод ради табуретки.
Вспомните порог Anthropic: до ~200K токенов (~500 страниц) RAG не нужен — всё в промпт с кэшированием. 80 страниц — ровно этот случай.
Что из этого оплачивается при КАЖДОМ вопросе пользователя?
Именно! Это конвейер 2 — он крутится на каждый вопрос. Парсинг, нарезка и карта — конвейер 1, индексация: платится один раз и при обновлениях.
Парсинг и карта — это индексация (конвейер 1), она делается заранее. На каждый вопрос работает конвейер 2: поиск → реранкер → генерация.
Какое изменение заставит пересчитать ВСЮ базу заново (самый дорогой сценарий)?
Верно! Новая модель = новая карта: все точки считались старой моделью, их придётся пересчитать. Один обновлённый документ переиндексируется точечно, а число вопросов на индексацию не влияет вообще.
Один документ обновляется точечно, рост вопросов нагружает только конвейер 2. А вот смена модели или нарезки меняет правила построения карты — пересчитывается всё.
Разработчик: «Сдам ассистента через месяц, протестируем на 20 вопросах — и готово». Что не так?
Именно! Реальные вопросы всегда отличаются от тестовых (вывод Seven Failure Points). Дело не в количестве тестов, а в том, что настройка продолжается после запуска — это должно быть в договоре.
Дело не в числе тестовых вопросов. Реальные вопросы пользователей всегда другие — поэтому RAG валидируется в эксплуатации, и «после запуска» должно быть в договоре.
Практика: проверьте свою базу на пороге
🛠 Задание на 5 минут
Выберите реальную базу знаний для будущего ассистента (материалы школы, регламенты, FAQ).
Откройте Claude Code в папке с этими документами и спросите: «Оцени общий объём этих документов в токенах. Порог — 200 тысяч токенов (~500 страниц): если меньше, RAG не нужен, достаточно длинного контекста с кэшированием. Что у нас?»
Запишите результат — это первая строка раздела «Знания» вашего будущего ТЗ.
Что дальше
Если RAG всё-таки нужен — следующий урок про самый недооценённый участок: подготовку и нарезку базы. Именно там, по статистике, умирает большинство RAG-проектов — ещё до всякого ИИ.