Какой тезис о RAG отстаивает спикер в этом докладе?

«Простой RAG» (одноразовый вектор-поиск) уходит, но retrieval как идея жив и эволюционирует в итеративный агентный поиск. Верно: спикер раскрывает RAG как Retrieval-Augmented Generation — «мёртв» именно наивный сценарий «один раз дёрнули вектор-поиск и закинули в контекст». Сам retrieval не исчезает: он становится богаче (вектор-поиск, BM25, grep, фильтры) и встраивается в итеративный цикл агента. Заголовок «RAG is dead, right?» — провокация, а не вывод.

Спикер показал график объёма поиска Google по теме за несколько лет. Зачем он его привёл?

Чтобы опровергнуть твиттер-нарратив: реальный интерес не падает, а в середине 2025 резко вырос. Верно: график — контраргумент к хайпу «RAG мёртв». Несмотря на волну твитов, объём поиска не угасает: рост в 2023, плато, а в середине 2025 — новая точка перегиба и резкий взлёт. Это эмпирическое возражение настроению соцсетей.

Почему Cursor использует деревья Меркла (Merkle trees) при индексации кодовых баз?

Чтобы сравнивать сходство кодовых баз, открываемых командой, и переиндексировать только изменённые файлы. Верно: идея в экономии — в команде из 100 инженеров почти все открывают одни и те же 1–2 репозитория, а заново чанковать, эмбедить и заливать всё каждый раз дорого. Хеш-дерево Меркла позволяет вычислить сходство баз и при достаточном совпадении скопировать готовые данные, переобработав лишь изменившиеся файлы.

Cursor сообщает о приросте точности ~12–13% (и до ~24% у Composer), но в онлайн A/B-тесте метрики выглядят скромно (~2,6% удержания кода, ~2,2% меньше недовольных запросов). Как спикер объясняет этот разрыв?

Семантический поиск нужен не каждому запросу, поэтому в среднем по всем запросам эффект «размывается». Верно: малые числа в A/B обманчивы — инструмент применяется не во всех 100 случайных запросах, многие просто не выигрывают от семантического поиска. Поэтому усреднённый по всем запросам эффект кажется небольшим, хотя там, где инструмент реально нужен, прирост существенный.

Что означает идея «embeddings и семантический поиск — это cached compute», проиллюстрированная сравнением трейсов Claude Code и Cursor?

Без индекса агент каждую сессию заново «grep–read–assess» (повторные вычисления и токены); индексация переносит эту работу в разовый upfront-расчёт. Верно: Claude Code открывает контекст «по сессии» — чтобы понять, как работает, скажем, фильтрация метаданных, он каждый раз grep–read–assess–repeat, и так 10 агентов × 10 дней повторяют одни и те же шаги, сжигая токены. Cursor же платит один раз за индексацию, а потом дёшево достаёт ответ на runtime. Эмбеддинги «кэшируют» понимание кодовой базы, чтобы не пересчитывать его заново.

Разборы · Статья: 14 июня 2026 г. · Видео: 9 июня 2026 г. · ~11 мин

RAG не умер, а вырос в итеративный agentic-поиск: эмбеддинги как кэш вычислений

Name: RAG is dead, right? — Kuba Rogut
Uploaded: 2026-06-09T00:00:00.000Z
Description: Доклад TurboPuffer: почему «RAG = один вектор-поиск в контекст» устарел, но retrieval жив и стал итеративным поиском агента с набором инструментов. Эмбеддинги как кэш вычислений — на метриках Cursor, Claude Code и цитате Jeff Dean.

Доклад TurboPuffer: почему «RAG = один вектор-поиск в контекст» устарел, но retrieval жив и стал итеративным поиском агента с набором инструментов. Эмбеддинги как кэш вычислений — на метриках Cursor, Claude Code и цитате Jeff Dean.

ИИ Программирование

Смотреть на YouTube

RAG is dead, right? — Kuba Rogut

TurboPuffer · Kuba Rogut · ~11 мин

Коротко

Простой «RAG = один вызов вектора в контекст» устарел, но сам retrieval жив и превратился в итеративный поиск агента с набором инструментов (вектор, BM25, grep). Эмбеддинги стоит понимать как кэш вычислений: разовая индексация экономит токены и поднимает точность ответов, что подтверждают метрики Cursor.

Оценка видео

Чем выше — тем больше пользы на минуту

3.5

средняя из 5

Актуальность информации 5.0

Свежий доклад (нач. 2026), ссылки на кейсы Cursor, Claude Code, цитату Jeff Dean — всё на острие темы.

Содержательность 3.0

За 11 минут есть один ясный тезис и пара конкретных цифр, но много общих слов и саморекламы TurboPuffer; глубины реализации нет.

Инновационность идей 3.0

Рамка «embeddings = cache compute» и «нужен не триллион, а правильный миллион» свежо поданы, но по сути это переупаковка известного спора RAG vs agentic.

Применимость на практике 3.0

Понятна развилка «grep каждый раз vs разовая индексация» и когда что выгодно, но без рецептов внедрения — только направление мысли.

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 «RAG мёртв» — это спор о терминах, а не о технологии

То, что в твиттере называют «agentic search» (grep по файлам), и есть retrieval — просто без заранее построенного индекса. RAG не умер, умерла его примитивная трактовка «один вектор-поиск → контекст»; объём поисковых запросов на retrieval, наоборот, резко вырос в 2025.

02 Эмбеддинги и семантический поиск — это кэш вычислений

Без индекса агент каждую сессию заново грепает, читает, оценивает и повторяет, чтобы понять одно и то же — и так у 10 разработчиков по 10 раз в день, сжигая токены. Индекс — это закэшированный результат этого «понимания», который превращает повторяющуюся дорогую работу в один разовый upfront-расход.

03 Retrieval перестал быть разовым вызовом и стал циклом рассуждения

Современный агент ищет, чтобы понять, и понимает, чтобы искать дальше — несколько шагов, разные инструменты, добор только нужного. Поиск встроен в reasoning, а не предшествует ему.

04 Узкое место — не размер контекстного окна, а отбор

Даже триллион токенов контекста не отменяет необходимости retrieval: «тебе не нужен триллион сразу, тебе нужен правильный миллион» (Jeff Dean). Ставка на гигантские окна вместо ступенчатого отбора — ложный путь.

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

Не выбрасывай RAG — расширь «retrieval» до набора инструментов

Дай агенту не только векторный поиск, а полный набор: full-text/BM25, grep, glob, regex, обычные фильтры — и позволь ему итеративно их комбинировать, пока он не наберёт нужный контекст. Один разовый вектор-поиск с закидыванием в контекст устарел (работало в 2023 — начале 2024).

Индексируй то, что переиспользуется много раз; grepай то, что одноразово

Если по одной кодовой базе/корпусу 100 человек задают похожие вопросы каждый день, заплати один раз за парсинг + эмбеддинг и дай агенту лёгкий инструмент поиска во время выполнения. Если контент уникален для сессии — дешевле грепать на лету, чем строить индекс.

Не дублируй индексацию похожих корпусов — сравнивай их хешами

По примеру Cursor: считай Merkle-дерево (хеш-дерево) по кодовым базам, и если новая ветка/база достаточно похожа на уже проиндексированную — копируй готовые данные и переиндексируй только изменившиеся файлы вместо полного re-chunk/re-embed.

Строй retrieval как двухступенчатую воронку, а не как «всё в контекст»

Даже при огромном контекстном окне сначала лёгким механизмом сузь триллионы токенов до «правильного миллиона / 100k / 10k», и только это передавай модели. Цель — не «дать всё», а «дать нужное».

Измеряй пользу retrieval честной A/B-метрикой, а не средним по всем запросам

Семантический поиск помогает не каждому запросу, поэтому средний прирост выглядит скромно (2–3% retention). Смотри на прирост точности там, где инструмент реально срабатывал (у Cursor — +12–24% accuracy), и на снижение неудовлетворённых запросов.

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод

Предпосылка Соцсети: «RAG мёртв»

В твиттере волна заявлений, что RAG устарел и его заменяет «agentic search» — grep по файлам.
Аргумент Но данные поиска: интерес к RAG, наоборот, вырос

График объёма поиска Google: рост в 2023, плато, а в середине 2025 — новая точка перегиба и резкий взлёт. Эмпирическое возражение настроению соцсетей.
Аргумент Значит, спор — о терминах, а не о технологии

RAG = Retrieval-Augmented Generation, а не только вектор-поиск. «Agentic search» — тот же retrieval, но набором инструментов и итеративно.
Аргумент Тезис: умер примитивный RAG, retrieval живёт и стал циклом

Мёртв наивный сценарий «один раз дёрнули вектор-поиск → контекст». Сам retrieval становится богаче (вектор, BM25, grep, фильтры) и встраивается в reasoning агента.
Пример Развилка цены: грепать заново каждую сессию ИЛИ закэшировать понимание в индекс

Claude Code каждую сессию grep–read–assess–repeat; Cursor платит один раз за индексацию (парсинг + эмбеддинг), потом дёшево достаёт ответ. Эмбеддинги = cached compute. Дедупликация похожих баз — через деревья Меркла.
Пример Честная метрика: прирост там, где инструмент сработал

У Cursor внутренний бенчмарк +12–24% accuracy, но в онлайн A/B ~2,6% retention — потому что семантический поиск нужен не каждому запросу, и средний эффект «размывается».
Вывод Вывод: ступенчатый отбор важнее размера окна — добываем не всё, а нужное

«Тебе не нужен триллион сразу, тебе нужен правильный миллион» (Jeff Dean). Узкое место — отбор, а не размер контекста.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Стоит ли смотреть целиком

Достаточно этой заметки — ключевой тезис («умер примитивный RAG, retrieval жив и стал итеративным циклом») и цифры (Cursor +12–24% accuracy против ~2,6% retention в A/B, дедупликация по деревьям Меркла) пересказываются за минуту. Остальные 11 минут — общие слова и промо вендора TurboPuffer.

Кому полезно

Инженерам, которые строят агентов и RAG-пайплайны и решают, индексировать корпус или грепать на лету; продактам и тимлидам, выбирающим между ставкой на гигантское контекстное окно и ступенчатый retrieval; всем, кто устал от спора «RAG мёртв / жив» и хочет разложить его по сути, а не по терминам.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 4

Шаг 1. Сегодня: проверь, чем реально ищет твой агент Выпиши, чем сейчас пользуется агент при поиске. Если это только разовый вектор-поиск «в контекст» — это и есть устаревшая схема, которую надо менять.
Шаг 2. На этой неделе: добавь не-векторные инструменты и итеративный цикл Дай агенту минимум один не-векторный инструмент (grep/BM25/фильтры) и разреши цикл «искать → читать → оценить → искать снова». Раздели корпус на «переиспользуемый» (индексировать заранее) и «одноразовый» (грепать на лету).
Шаг 3. Закрепить: A/B-метрика и дедупликация индекса Поставь A/B-тест с метрикой точности именно на запросах, где инструмент сработал; для повторяющихся корпусов внедри дедупликацию индекса по хешам (Merkle-дерево), чтобы не переиндексировать всё заново.
Шаг 4. Проверь, что сработало Падает число токенов/повторных проходов на типовой запрос, растёт accuracy на запросах с retrieval и снижается доля неудовлетворённых ответов — при том, что upfront-стоимость индексации окупается за счёт многократного переиспользования.

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 5 Верно: 0

1. Какой тезис о RAG отстаивает спикер в этом докладе?
2. Спикер показал график объёма поиска Google по теме за несколько лет. Зачем он его привёл?
3. Почему Cursor использует деревья Меркла (Merkle trees) при индексации кодовых баз?
4. Cursor сообщает о приросте точности ~12–13% (и до ~24% у Composer), но в онлайн A/B-тесте метрики выглядят скромно (~2,6% удержания кода, ~2,2% меньше недовольных запросов). Как спикер объясняет этот разрыв?
5. Что означает идея «embeddings и семантический поиск — это cached compute», проиллюстрированная сравнением трейсов Claude Code и Cursor?