RAG проще, чем вы думаете: 6 архитектур без переусложнения
RAG Is Simpler Than You Think
Многие перегружают свои RAG-системы эмбеддингами и векторными базами, хотя пользователям часто нужен просто поиск по ключевым словам. Автор разбирает шесть архитектур — от простого BM25 до агентного RAG — и объясняет, как выбрать подходящую, исходя из свежести данных, характера корпуса, паттернов запросов, масштаба и возможностей команды. Главный совет: начинайте с простого и усложняйте только тогда, когда есть данные, подтверждающие необходимость. Также рассматриваются переписывание запросов с помощью LLM, гибридный поиск, горячие/холодные уровни и полное пре-эмбеддинг, с оценкой стоимости и задержек.
Большинство «семантических» проблем поиска — это на самом деле проблемы формулировки запроса.
- usernametaken29
Я раньше работал с крупномасштабными RAG-системами и могу сказать, что люди сильно недооценивают полнотекстовый поиск и сильно переоценивают эмбеддинги. Полнотекстовый поиск действительно прост, портативен и масштабируем, и с ним можно далеко уйти, здесь работает правило 80/20. Эмбеддинги выглядят красиво и волшебно, но когда начинаешь в них разбираться, замечаешь: семантическая схожесть не так хороша, как ты думаешь, и уж точно не удовлетворит всех. Ты неизбежно окажешься в ситуации, когда придётся пересоздавать эмбеддинги для большего или другого количества фрагментов текста, чтобы обеспечить более точный поиск по эмбеддингам — и в этот момент ты пойдёшь до конца и добавишь реранжирование и так далее, при этом всё время поддерживая операционную нагрузку векторного поиска.
А потом ты разворачиваешься и строишь поисковый запрос из 500 ключевых слов, и, конечно, это мучительно, но это просто работает, покрывает все сценарии использования, масштабируется и в целом менее раздражает в обслуживании.
- alansaber
Я создавал системы, использующие все эти подходы (все вместе). По большей части, овчинка выделки не стоит (если речь о создании высокооптимизированной стратегии поиска информации, специфичной для конкретного корпуса), за исключением очень немногих крайних случаев. Объём технических обсуждений намного превышает реальную потребность в RAG.
- jillesvangurp
RAG — это, по сути, старый добрый информационный поиск, где LLM выполняют запросы. Это может включать векторный поиск, но работает и без него. Относиться к векторному поиску как к волшебной пыльце, которая делает поиск отличным без усилий, — не обязательно сработает. Кроме того, это может добавить много затрат и сложности. И если не настроить должным образом, результаты не обязательно будут хорошими.
Ключевой момент в RAG — получить нужную информацию в контексте с как можно меньшим количеством запросов. Это требует хорошего recall (убедиться, что если информация там есть, её можно найти разумным запросом) и precision (убедиться, что лучшие результаты сверху и минимизировать ложные срабатывания).
В поиске, и, соответственно, в RAG, действует принцип «мусор на входе — мусор на выходе». Большая часть того, что команды поиска делали до ИИ и RAG, по-прежнему является лучшим способом оптимизировать работу с RAG. И если вы испортите это, поиск не будет работать хорошо, и никакое количество ИИ не сможет это компенсировать, или только ценой больших затрат на токены и время. Поэтому наличие ETL-пайплайна для предварительной обработки индексируемого контента, тестирование и бенчмаркинг качества поиска и т.д. — всё это полезно.
Хорошая новость в том, что для создания чего-то приемлемого не нужно много навыков в агентном программировании. Этот код почти пишет сам себя. И даже небольшие усилия по извлечению структуры перед индексацией могут иметь большое значение.
- jrochkind1
Ещё один текст, сгенерированный LLM, о LLM.
Кому-нибудь ещё становится всё труднее и труднее читать тексты, сгенерированные LLM? Я нахожу это очень утомительным, мой мозг просто не хочет через это продираться.
- Angostura
У меня особая антипатия к статьям, которые слишком ленивы, чтобы расшифровать аббревиатуры при первом использовании.
Итак: https://en.wikipedia.org/wiki/Retrieval-augmented_generation
- yipinwong
Только те, кто овладел мастерством, заставляют свою работу выглядеть простой.
ИИ, который написал это, возможно, и есть мастер, а не автор, так как это выглядит написанным ИИ.
Я воспользуюсь агентами автора, но не буду читать его статьи или нанимать его для работы.
- refactor_master
Вот ещё более простой подход: просто встройте всё сразу, а затем отслеживайте, что изменилось. Используйте дешёвую модель для суммаризации и очистки документов/чатов с помощью сводок и ключевых слов. Если только у вас нет целых библиотек книг для встраивания, это будет стоить несколько сотен долларов на API-вызовы.
Затем закиньте всё в BigQuery. Он нативно обрабатывает все векторные штуки.
Добавьте агентный UI-бот сверху, чтобы всё выглядело всезнающим и волшебным.
Полагаю, у других вендоров, кроме Google, есть аналогичный подход «всё включено», который можно просто подключить.
- klm127
RAG означает Retrieval Augmented Generation. Цель — искать по корпусу текста по смыслу, а не по точному совпадению.
Мне пришлось это искать.