ainews
RAG — решение проблемы, которой у большинства команд нет
Команды добавляют векторные БД и RAG при падении качества ответов, хотя реальная проблема — не в поиске информации, а в том, что модель не может выбрать из кучи релевантных документов действительно важный. RAG автоматизирует подачу того же мусора, не решая проблему приоритизации контекста.
Если вы строите AI-продукт на базе знаний, этот аргумент заставляет проверить: действительно ли вам нужна инфраструктура RAG, или достаточно лучше отобрать и приоритизировать контекст. Экономит время, деньги и нервы.
Что произошло
Пост-критика на Reddit о том, что индустрия злоупотребляет RAG (Retrieval-Augmented Generation) там, где он не нужен. Автор утверждает: когда падает качество ответов AI на задачах с большой базой знаний, команды рефлекторно добавляют векторные БД и системы поиска. Но чаще всего проблема не в retrieval (поиске документов), а в curation (кураторстве контекста).
Модель не страдает от нехватки информации — она тонет в слабо релевантных документах, не понимая, какой из них действительно важен для конкретного вопроса. RAG автоматизирует подачу ещё большего объёма такой же каши. После внедрения RAG проблема не исчезает, а меняет форму: ответы становятся более фактологичными (факты технически присутствуют), но более размытыми, потому что модель всё ещё не может выбрать из пяти найденных чанков тот единственный, который критически важен.
Автор признаёт, что RAG оправдан для действительно больших, постоянно меняющихся корпусов (legal discovery, огромные кодовые базы), где нельзя вручную отобрать релевантное. Но для большинства внутренних инструментов и продуктов правильное решение банальнее: вручную отсеять источники до структурно релевантных для задачи ещё до того, как они попадут в контекст модели. Команды пропускают этот шаг, потому что он требует думать о данных, и вместо этого берут готовый паттерн с тулингом — RAG.
Автор: Никита Громов · Источник: reddit.com
Разработчикам. Не добавляйте векторные БД автоматически при падении качества. Сначала проверьте: может, модель получает слишком много шума? Попробуйте жёстче кураторство источников, фильтрацию чанков по структурной релевантности, приоритизацию контекста. RAG — это инфраструктурный overhead, который нужен только когда корпус действительно огромен и динамичен.
Бизнесу. Команды тратят время и деньги на внедрение RAG там, где достаточно лучше отобрать документы вручную. Результат: сложность растёт, качество остаётся посредственным. Перед инвестициями в векторные БД стоит проверить, не решается ли проблема более простой кураторской работой над данными.
Инвесторам. Рынок RAG-инструментов переоценён для сценариев малых и средних корпусов знаний. Реальная потребность — в инструментах кураторства контекста, приоритизации, структурирования данных до этапа поиска. Продукты, которые помогают отбирать и взвешивать контекст умнее, могут обойти чистые RAG-решения.
- Инструмент для автоматического ранжирования и приоритизации чанков в контексте по структурной релевантности к запросу, не только по семантическому сходству
- Сервис аудита качества данных для RAG-пайплайнов: анализ, какие чанки реально влияют на ответы, а какие — шум
- Консалтинг по оптимизации контекста для AI-продуктов: помогать командам сократить корпус знаний до действительно критичного, вместо внедрения RAG
- Платформа для кураторства корпоративных знаний: управление тем, что попадает в контекст, с метаданными приоритета и структурой для разных типов запросов
- Тулинг для A/B-тестирования стратегий контекста: сравнение RAG vs ручная кураторство vs гибридные подходы с метриками качества
- Риск упрощения: есть домены, где RAG действительно критичен (например, динамичные правовые базы), и отказ от него ради кураторства убьёт продукт
- Ручная кураторство масштабируется плохо: для растущего корпуса знаний ручной отбор документов быстро превращается в узкое горлышко
- Автор не даёт конкретных кейсов, где кураторство победило RAG — это мнение, не подкреплённое данными, может быть предвзятостью
- Команды могут использовать этот аргумент как отговорку, чтобы не внедрять RAG там, где он на самом деле нужен, теряя конкурентное преимущество
Автор прав в том, что RAG стал cargo cult паттерном: все добавляют, потому что так делают, а не потому что он решает их конкретную проблему. Реально видел проекты, где после внедрения Pinecone качество не выросло, зато появилась ещё одна движущаяся часть, которая ломается. Но есть нюанс: ручная кураторство масштабируется до определённого момента, а потом всё равно упираешься в RAG. Вопрос не "RAG или нет", а "на каком этапе он действительно нужен".
Ключевой инсайт здесь не про RAG, а про то, что команды не понимают, какую проблему они решают. Если модель тупит, потому что в контексте 10 документов и все примерно релевантны, RAG подаст 15 таких же. Решение — не больше документов, а лучше фильтрация и приоритизация. Это скучно, потому что требует разбираться в данных, а не просто подключить очередной SaaS. Но работает.
Комментарии