В уроке 4 мы сказали: «векторная база перестала быть обязательной», Anthropic выбрала для Claude Code агентный поиск — и он «победил с большим отрывом». А потом целый блок строили RAG. Выглядит как противоречие, и вопрос «так что же выбирать?» — законный.
Разгадка в том, что у этих историй разная нагрузка. Claude Code — инструмент одного человека: десятки запросов в день, пользователь готов подождать полминуты, код меняется ежеминутно. Ассистент школы — сервис для сотен учеников: ответ нужен за секунды, и платить «агентскую» цену за каждый из сотен ответов разорительно.
Запомните формулу: агентный поиск — инструмент для своих, RAG — сервис для толпы. Дальше разберём, почему это так с точностью до денег.
Вспомните цикл из урока 1: модель думает → зовёт инструмент → смотрит результат → думает дальше. Агентный поиск — этот же цикл, где инструменты — простейшие: поиск по словам в файлах (grep), просмотр списка файлов, чтение найденного.
Ключевое отличие от RAG: в RAG поиск — один заранее настроенный шаг конвейера. Здесь поиском управляет сама модель: не нашла — переформулирует, нашла обрывок — пойдёт по ссылке в соседний документ, усомнилась — перепроверит. Слабость инструмента (grep ищет только точные слова) компенсируется умом того, кто им пользуется.
Векторный поиск понимает перефразировки («вернуть деньги» ≈ «процедура возврата средств»), а grep — нет. Казалось бы, агентный поиск должен проигрывать разгромно. Но синонимы знает сама модель: не нашла по «возврат» — попробует «refund», «аннулирование», «отмена заказа». Карта смыслов размазана по витку цикла.
Исследование мая 2026 на реальных корпусах это подтвердило: агент с поиском по ключевым словам достигает 90%+ качества полноценного RAG-конвейера. Цена — токены: каждая попытка, каждый прочитанный файл, каждое «подумаю ещё» оплачивается. (Is Grep All You Need?, arXiv, май 2026)
Отсюда и потолок: на огромных базах (сотни тысяч документов) перебор «поищу так, поищу эдак» буксует — индекс, который сузил поле за миллисекунды, становится незаменим.
Платите за конвейер заранее: парсинг, нарезка, индексация, инфраструктура ($20–80/мес для школы, урок 14). Зато каждый ответ — один поиск + одна генерация: секунды и копейки.
Входа нет вообще: положили файлы в папку — работает. Зато каждый ответ — несколько витков цикла: в разы больше токенов и десятки секунд ожидания.
Теперь видно, где экономика переворачивается: при единицах-десятках запросов в день дорогая цена ответа незаметна, а отсутствие инфраструктуры — счастье. При сотнях запросов в день дорогие ответы складываются в разорительный счёт, а вложение в конвейер размазывается и окупается.
Это та же логика, что у такси и личного авто: ездите дважды в месяц — такси (платите за поездку), ездите каждый день — своя машина (платите за владение). Спорить «что лучше» без вопроса «сколько ездите» бессмысленно.
У RAG между документом и ответом стоит индекс. Обновили тариф — пока не переиндексировали, ассистент цитирует старый (помните сценарий из урока 13?). Процесс обновления — отдельная работа и статья бюджета (урок 14).
Агентный поиск читает оригиналы. Поправили файл — следующий же ответ опирается на новую версию. Для баз, которые меняются ежедневно (переписки, код, рабочие документы запуска), это не бонус, а решающий аргумент: индекс устаревал бы быстрее, чем переиндексируется.
Именно поэтому Claude Code работает без индекса: Anthropic пробовала векторную базу по коду — агентный поиск победил «с большим отрывом», в том числе потому, что код меняется при каждом сохранении файла. (разбор с цитатами создателя Claude Code, март 2026)
Для внутреннего помощника не нужен разработчик:
тарифы-2026.md найдётся, doc_final_v3(2).pdf — нет. Устаревшие версии — в архивную папку: мусор на входе портит и агентный поиск, не только RAG.Сравните со сметой RAG-проекта из урока 14 — и станет ясно, почему дерево выбора велит начинать с простого пути.
Папка с файлами — это полки. Следующий шаг — дорожные указатели: нарежьте знания на файлы по одной концепции и проставьте между ними обычные ссылки со смыслом: «опирается на…», «см. также…», «частный случай…». Так устроены базы заметок вроде Obsidian (метод Zettelkasten — «картотека»: одна мысль = одна карточка, карточки связаны).
Для агента это меняет всё. Без ссылок он блуждает: ищет по словам, гадает, где продолжение. Со ссылками — движется по маршруту: открыл файл про модуль курса, увидел «возражения разобраны в [vozrazheniya.md]» — пошёл туда. Тот же agent loop, но теперь структура базы подсказывает следующий шаг.
Получается граф знаний: узлы — файлы-концепции, рёбра — ссылки. Никакой инфраструктуры — граф живёт прямо в текстах. Добавьте файл-карту (оглавление со ссылками на главное) — это «вход» в граф, с которого агент начинает.
Связи и сами файлы может строить агент — по заданным вами правилам. Этот паттерн в марте 2026 показал Андрей Карпати (сооснователь OpenAI, экс-глава ИИ в Tesla), и его схема многих вдохновила. Он называет это компиляцией знаний: как компилятор превращает сырой код в работающую программу, агент превращает сырые материалы в организованную вики.
Устройство — три части. Папка raw/ — сырьё как есть: статьи, PDF, заметки, с дублями и мусором, его никто не причёсывает. Папка wiki/ — результат: агент читает сырьё и переписывает его в маленькие статьи-концепции — выделяет суть, убирает дублирование, перелинковывает статьи между собой, ведёт файл-индекс.
Третья часть — файл-схема с правилами (тот же формат, что CLAUDE.md): как структурировать статьи, как вливать новые источники, что делать с противоречиями. Именно схема превращает универсального агента в дисциплинированного хранителя вики.
Человек в этой системе — главный редактор, а не писарь: подкладывает сырьё и читает результат. У самого Карпати такая вики — ~100 статей на 400+ тысяч слов, и на вопросы агент отвечает без всякого RAG — агентным поиском по индексу и ссылкам. (разбор метода Карпати, апр. 2026; пересказ на русском)
Заметьте, как это ложится в экономику урока: компиляция — та же «индексация», разовая дорогая переработка. Только результат — не векторы в базе, а читаемые файлы, которые видно глазами и можно править.
Одна честная оговорка: агент при переписывании может упростить или исказить. Для бизнес-базы (тарифы, обещания клиентам) заложите выборочную сверку статей с сырьём — тот же принцип честности из урока 13.
Звучит похоже на GraphRAG — но это разные вещи. В GraphRAG граф строит машина: LLM прочитывает корпус, автоматически извлекает сущности и связи, складывает их в отдельную графовую базу данных. Отсюда его цена: извлечение сжигает токенов больше, чем весь корпус, ошибается, а базу надо обслуживать (урок 12: ниша, 3–5× дороже).
Граф ссылок — неважно, проставили вы их руками или построил агент-компилятор по вашей схеме — остаётся обычными файлами: его видно глазами, он правится в любом редакторе, инфраструктуры ноль, читает его агентный поиск. А по графовой базе GraphRAG ходят специальные запросы — как текст её не почитаешь.
И бонус на вырост: если нагрузка вырастет и придётся строить RAG, такая база — подарок для индексации. Чанки уже нарезаны по одной мысли, а контекст, который contextual retrieval дописывает за деньги (урок 11), у вас уже проставлен ссылками и заголовками.
Похожие названия, разные вещи — их путают чаще всего. Агентный поиск (agentic search) — индекса нет вообще: агент ищет по живым файлам. Агентный RAG (agentic RAG, урок 14) — агент работает поверх готового RAG-конвейера: решает, в каком индексе искать, не переформулировать ли запрос, достаточно ли найденного.
То есть агентный RAG — это «RAG + мозги», апгрейд конвейера. А агентный поиск — «мозги вместо конвейера», его замена. В разговоре с разработчиком уточняйте, о чём речь: «агентный поиск по файлам, без индекса?» или «агент поверх векторной базы?» — это разные сметы и разные архитектуры.
«Если такие вопросы будут задавать 300 учеников в день через сайт — останется ли агентный поиск правильной архитектурой? Посчитай и сравни с RAG». Сверьте его рассуждение с деревом выбора.Теперь в руках обе архитектуры и дерево, которое их разводит. Финал блока — собрать всё в детальный раздел «Знания» вашего ТЗ: урок 16.