«Хочу ассистента, который отвечает по нашим регламентам / курсам / переписке с клиентами». База знаний — сотни документов, в окно целиком не лезет (а если и лезет — вы помните из урока 2 про context rot и цену каждого токена). Значит, нужен механизм, который к каждому вопросу подтягивает в контекст только релевантное. Таких механизмов три.
Если база компактная (до ~сотни страниц) — кладём её в контекст целиком, без всякого поиска.
✚ Ноль инфраструктуры, модель видит всю картину сразу, нет риска «не нашли нужный кусок».
− Платите за все токены при каждом запросе; на больших объёмах — context rot и дорого.
Подходит: FAQ, один регламент, описание продуктовой линейки.
RAG — конвейер. Сначала документы режутся на небольшие кусочки — их называют чанками (chunk — «ломоть»): абзац-два, чтобы кусочек был про одну вещь.
Дальше главный фокус. Представьте огромную карту, где у каждого кусочка текста есть своя точка, и расставлены точки по смыслу: «как вернуть деньги» и «процедура возврата средств» — соседи, а «график отпусков» — на другом краю карты.
Координаты точки на этой карте и называются эмбеддингом (embedding — «вложение»: текст как бы вкладывается в пространство смыслов). Для наглядности представляйте карту трёхмерной — в реальности измерений сотни.
Все точки складываются в векторную базу — хранилище, которое умеет молниеносно отвечать на один вопрос: «кто ближайшие соседи вот этой точки?».
Когда пользователь что-то спрашивает, его вопрос тоже получает точку на карте. База находит кусочки-соседи, кладёт их модели в контекст — и модель отвечает. Так и получается поиск по смыслу, а не по словам.
✚ Масштабируется на миллионы документов; дёшев и быстр на каждом запросе; появились сервисы «под ключ» (managed): вы просто загружаете документы, а нарезку, карту смыслов и поиск провайдер делает сам — OpenAI Vector Stores и аналоги. (доки OpenAI)
− Это конвейер из многих шагов, и каждый может подвести: неудачная нарезка, «не та» похожесть, устаревший индекс (добавили документ — надо переиндексировать).
− К тому же «чистого» поиска по карте смыслов в продакшне недостаточно — нужны две надстройки: гибридный поиск и реранкер.
Гибридный поиск — это когда к поиску по смыслу добавляют обычный поиск по точным словам. Карта смыслов отлично понимает перефразировки, но теряет точное: артикул «СБ-1042», фамилию, номер договора — для неё это странные слова без внятного смысла. Поиск по точным словам их добирает.
Реранкер (reranker — «пересортировщик») лечит другую слабость: быстрый поиск по карте работает приблизительно. Он приносит, скажем, 50 кандидатов, и нужные там перемешаны со случайными соседями.
Реранкер — внимательный «второй читатель»: отдельная модель перечитывает каждого кандидата рядом с вопросом и пересортировывает список — наверх поднимаются те, что действительно на вопрос отвечают.
Связка работает: по данным Anthropic, добавление контекста к чанкам + реранкер снижают долю неудачных поисков на 67%. (Anthropic, Contextual Retrieval, Weaviate, Hybrid Search)
Карту смыслов рисует эмбеддинг-модель — отдельная нейросеть, обученная на миллионах пар «эти тексты об одном / о разном». Она картограф: расставляет точки заранее, на этапе индексации, не зная, какие вопросы будут задавать. Весь смысл абзаца сжимается в одну точку — отсюда скорость, и отсюда же приблизительность.
Реранкер — модель другого типа: кросс-энкодер (cross-encoder — «перекрёстный кодировщик»). Она читает вопрос и кандидата вместе, одной парой, и может сопоставлять их слово со словом: «спрашивают про возврат аванса, а абзац — про возврат товара, мимо».
Почему тогда не искать реранкером сразу по всей базе? Цена. Эмбеддинг каждого документа считается один раз заранее, а реранкеру нужен отдельный прогон на каждую пару «вопрос + кандидат» — миллион документов так не перечитаешь. Отсюда двухэтажная схема: быстрая карта отбирает ~50 кандидатов, внимательный читатель перечитывает только их.
Реранкеры — небольшие специализированные модели, заметно дешевле чатовых LLM. Их берут готовыми: Cohere Rerank, Voyage Rerank, открытое семейство bge-reranker.
Подходит: большие базы (тысячи документов), высокая частота запросов, нужен дешёвый и быстрый ответ.
Никакого индекса. Знания лежат файлами, а агент ищет по ним в цикле обычными инструментами: поиск по словам (grep), просмотр структуры, чтение найденного — и сам решает, где искать дальше, переформулирует запрос, проверяет соседние файлы. Это то, что Claude Code делает с вашими проектами каждый день.
✚ Ноль инфраструктуры; данные всегда свежие (читаем оригинал, а не индекс); агент «рассуждает» в процессе поиска. Anthropic пробовала в раннем Claude Code RAG с векторной базой — агентный поиск «победил с большим отрывом». (разбор с цитатами создателя Claude Code, март 2026)
− Каждый поиск — несколько витков цикла: медленнее и дороже по токенам на каждый запрос; на очень больших базах буксует. Исследования 2026: агентный поиск по ключевым словам даёт 90%+ качества RAG, но жжёт заметно больше токенов. (arXiv 2605.15184, май 2026)
Подходит: малые и средние базы, частые обновления, запросов немного, точность важнее скорости.
Обратите внимание: пути 2 и 3 различает не столько размер базы, сколько нагрузка — сколько запросов в день и кто ждёт ответа. Агентный поиск — инструмент для своих, RAG — сервис для толпы. Это каноническое дерево курса, в развёрнутом виде с примерами — в справочнике «Дерево выбора»; уроки дальше ссылаются именно на него.
Важный сдвиг 2026 года, о котором ваш разработчик может не знать: векторная база перестала быть обязательной. В 2023 «ассистент по базе знаний» автоматически означал «векторная база + эмбеддинги». Сегодня для малых и средних баз чаще выигрывает связка «файлы + агентный поиск + длинный контекст» — без единого нового сервиса. (разбор Akita, апр. 2026; RAGFlow, итоги 2025)
Но не делайте из этого вывод «RAG умер» — это вторая крайность. RAG незаменим там, где запросов много и каждый ответ должен быть быстрым и дешёвым: ассистент для сотен учеников — это RAG, даже если та же база для внутреннего пользования прекрасно жила бы на агентном поиске. RAG просто перестал быть ответом по умолчанию — теперь это ответ на конкретный профиль задачи.
Оба пути курс разбирает всерьёз: RAG — уроки 10–14 (блок 2), агентный поиск на практике — урок 15.
«Спроектируй доступ к знаниям для такой задачи: [ваш кейс №1]. Сравни RAG, длинный контекст и агентный поиск, дай рекомендацию». Совпал ли его выбор с вашим? Если нет — у вас теперь есть знания, чтобы аргументированно спорить. 🙂Следующий урок — паттерны оркестрации: как из моделей и инструментов собираются системы посложнее — конвейеры, маршрутизаторы, оркестраторы с субагентами — и когда мультиагентность оправдана, а когда это дорогая игрушка.