RAG не умер, MCP не убили: как проверять хайп-тезисы

GitHub Blog на прошлой неделе разобрал три модных тезиса из разработческого твиттера разом: код читать не нужно, RAG себя изжил, а Skills добили MCP.

Каждый звучит убедительно в одном предложении и разваливается при первой проверке.

Компания платит за AI-инструменты живым бюджетом.

Разница между эффектным тезисом и рабочим решением для неё - это разница между вложением и списанием.

Автор GitHub Blog поймал себя на том, что хайп-тезисы - удобный формат для вовлечения и бесполезный для решений.

Читатель соглашается, спорит пять минут, листает дальше.

Читатель получает пользу из тезиса, только когда раскладывает его на условия: при каких обстоятельствах это правда, чего не хватает в формулировке, что меняется при переносе на реальную задачу. С RAG и MCP этот разбор особенно нагляден, потому что оба тезиса цепляют реальную технологию, но описывают её неточно.

RAG - это механизм: модель ищет релевантные фрагменты в векторной базе, добавляет их в промпт и только потом отвечает.

Он не заменяет агента с доступом к живым API, и здесь тезис отчасти прав - там, где данные можно получить прямым вызовом инструмента, лишний слой retrieval действительно избыточен.

Но там, где источник - закрытая база на тысячи документов: регламенты, каталог 1С, товарная таксономия в Pimcore или Akeneo - RAG остаётся единственным способом дать модели точный контекст без переобучения.

Тезис «RAG мёртв» путает частный случай с общим правилом.