TL;DR
RAW-RAG — это простая схема памяти для долгих диалогов. История хранится как есть, без пересказов, выжимок и графов. Она нарезается на куски, на вопрос находятся самые похожие куски, и модель сама разбирается, что из них актуально, а что устарело.
Главная находка: сложные «агентные» системы памяти (Mem0, MemOS, EverMemOS и другие) почти всегда не лучше этого простого подхода, а часто хуже. Когда LLM переписывает историю в «факты», «резюме» или «граф», она теряет детали, связи между событиями и порядок: что было до чего, что чем заменено. Потом на вопрос просто нечем ответить. Простая схема выигрывает не потому, что модель лучше читает, а потому, что нужный кусок вообще попал в запрос.
Суть метода в четырёх шагах: нарезать сырой текст с датами, найти кандидатов, переранжировать, отдать 15 лучших кусков модели. Самые тяжёлые операции (извлечение фактов, обновление и удаление записей) убраны полностью.
Схема метода
ШАГ 1 (индекс): сырой диалог + даты сообщений → куски по 256 токенов, перекрытие 32
ШАГ 2 (поиск): вопрос → 128 ближайших кусков по смыслу (эмбеддинги)
ШАГ 3 (переранжирование): модель-ранжировщик оценивает пары «вопрос–кусок» → топ-15
ШАГ 4 (ответ): вопрос + 15 кусков → LLM сама восстанавливает порядок событий и актуальное состояние
Шаги 1–3 выполняются кодом (эмбеддинги и ранжировщик). Шаг 4 — обычный запрос к LLM.
Пример применения
Сам RAW-RAG — это код. Но главный принцип, «храни сырьё, пусть модель сама разбирает хронологию», переносится в обычный чат или проект. Ниже пример в этой логике. Инструкция — наша обвязка, не промпт из статьи.
Задача: Основательница онлайн-школы ведёт 40 созвонов с ключевым B2B-клиентом. Договорённости менялись: цену сначала обсуждали 90 000 ₽, потом 75 000 ₽, дедлайн переносили дважды. Раньше она просила ChatGPT сжимать каждый созвон в «ключевые факты». Теперь пора готовиться к следующему звонку. Она загружает в Claude Project сырые транскрипты с датами и пишет инструкцию проекту.
Промпт (инструкция проекта):
Ты помогаешь готовиться к созвонам с клиентом «Школа Бизнеса Север».
Источник правды — только загруженные сырые транскрипты. Каждый файл назван датой звонка.
Правила:
1. Не опирайся на пересказы и выжимки, только на цитаты из транскриптов.
2. Если по одному вопросу (цена, сроки, объём) есть несколько версий — выстрой их по датам и назови актуальную. Актуальная — самая поздняя, если её явно не отменили.
3. Для каждого вывода дай цепочку: дата → что сказано → что изменилось.
4. Если нужного фрагмента в транскриптах нет, так и скажи. Не восстанавливай по догадке.
Вопрос: какие условия по цене и срокам сейчас действуют и что мы обещали в последний раз?
Результат: Модель выдаст хронологию по каждому пункту: цена, сроки, обещания. Рядом будут даты и цитаты, итоговая актуальная версия и пометка, если чего-то в записях нет. Видно, откуда взят каждый вывод, и это легко проверить.
Почему это работает
Слабость: когда LLM заранее пересказывает историю в «факты» и «резюме», она решает за вас, что важно. Решает без знания будущего вопроса. Исчезают детали, порядок событий и связи вроде «это отменило то». В статье такие пересказы давали худший результат, чем исходный текст.
Сильная сторона: современная модель хорошо разбирает хронологию и противоречия по сырому тексту. Если ей дать записи за разные даты, она сама определит, что устарело. В статье сильные модели решали задачи на удаление и каскадные изменения, когда видели достаточно исходных записей.
Как метод это использует: вся сложность убрана из хранения. Остаётся одна задача — донести до модели нужные куски. Оказалось, что системы различаются прежде всего тем, насколько полно они эти куски находят. Когда нужные куски уже в запросе, ответы у всех систем получаются примерно одинаково хорошими.
Рычаги, которые измерили: - Переранжирование (вторая оценка найденного) → без него точность заметно падала. Держи его. - Число кусков → от 5 до 60 примерно одинаково, 1 кусок — сильно хуже, 120 — тоже заметно хуже. Много не значит лучше. - Размер куска (128–1024 токена) → почти не влиял, подбирать не обязательно. - Добавки (факты, резюме, графы) → ни одна не помогла, все ухудшили.
Шаблон промпта
В статье нет готового промпта для читателя. Промпты извлечения фактов лежат в приложении, и они как раз то, что не нужно использовать. Ниже наш шаблон инструкции для «читателя» (модели, которая отвечает по сырой истории). Он следует логике статьи: сырой источник, модель сама определяет актуальность.
Ты отвечаешь на вопросы по сырой истории: {что_за_история}.
Источник правды — только приведённые фрагменты. Пересказам и выжимкам не доверяй.
Правила:
1. Фрагменты имеют даты. Восстанови порядок событий.
2. Если по {предмет_вопросов} есть несколько версий, выстрой их по времени и назови актуальную.
Версию считай устаревшей, если её заменили или отменили позже.
3. Для каждого вывода покажи цепочку: дата → фрагмент → что изменилось.
4. Если для ответа не хватает фрагментов, скажи, чего именно не хватает.
Фрагменты:
{сырые_фрагменты_с_датами}
Вопрос: {вопрос}
Что подставлять: {что_за_история} — переписка, созвоны, тикеты. {предмет_вопросов} — то, что меняется со временем: цена, статус, договорённости. {сырые_фрагменты_с_датами} — исходный текст, не пересказ. Даты обязательны.
Ограничения
⚠️ Слабая модель не справится с хронологией: в тесте на динамических задачах (удаление, каскады, отмены) самая слабая модель провалила почти всё, а сильные справились. Метод держится на том, что читатель умеет разбирать порядок событий. Слабой модели нужна помощь.
⚠️ Если история помещается в контекст — отдай целиком: на одном из тестов полный контекст сильно обошёл любой поиск. RAG нужен, когда истории слишком много, а не вместо контекста.
⚠️ Не «очень много кусков»: при слишком большой выдаче (120) точность упала. Нужны умеренный объём и переранжирование.
⚠️ Проверено только на текстовых диалогах: авторы прямо пишут, что интерактивные, мультимодальные и рабочие сценарии не проверены. Выводы относятся к тем бенчмаркам, которые они брали.
⚠️ Преимущество небольшое: над сильнейшей агентной системой RAW-RAG выигрывает на доли пункта в одном бенчмарке и на несколько пунктов в других. Честный вывод: «не хуже и сильно дешевле», а не «намного лучше».
⚠️ Хранение и приватность: сырая история хранится целиком, включая личные данные. Удаление по запросу и политика хранения усложняются.
⚠️ Сам RAW-RAG требует кода: эмбеддинги, ранжировщик и индекс собираются программно. Для чата переносится принцип, а не конвейер.
Как исследовали
Авторы начали с вопроса: нужна ли вся эта сложность? Сначала они проверили, как часто системы памяти вообще обновляют и удаляют записи. Взяли Mem0 и прогнали все диалоги LoCoMo и 500 примеров LongMemEval. Обновления и удаления составили единицы процентов решений, многие из них были дублями или с ошибками. Когда авторы заменили всё на «только добавлять», точность на LoCoMo выросла (с 67,4 до 69,4).
Затем они собрали RAW-RAG: нарезка, поиск 128 кандидатов, переранжирование до 15. Сравнили с 12 системами памяти на четырёх бенчмарках с несколькими моделями-читателями. RAW-RAG занял первое место в шести из семи комбинаций бенчмарк+модель. Он же оказался в 5–30 раз быстрее по обработке. На длинной истории (около миллиона токенов) загрузка заняла 0,33 часа против 3–27 часов у других.
Дальше они искали, почему. Разделили вопрос на «достали ли нужный кусок» и «правильно ли ответила модель, если достали». Системы сильно различались по первому (около 19–45%) и мало по второму (80–90%). Победа RAW-RAG объясняется охватом, а не умением модели.
Самый показательный опыт: к RAW-RAG добавили факты, резюме и графы. Все три добавки ухудшили результат. Извлечение фактов почти уничтожило задачи на обучение по примерам. Даже когда системам памяти давали идеальный доступ ко всему их хранилищу, они не догоняли сырой текст.
Практический вывод: если вы строите или выбираете память для ассистента, начните с хранения сырья и хорошего поиска. Сложную систему внедряйте, только если она обыгрывает такую базу на ваших задачах.
Адаптации и экстраполяции
🔧 Техника: «только дописывать» → меньше потерь
Аудит Mem0 показал, что запрет на изменение и удаление записей не ухудшил результат, а чуть улучшил. Для файла вроде CLAUDE.md или журнала проекта: добавь в инструкцию агенту «Журнал только дополняется. Старые записи не переписывай и не сокращай. Если что-то изменилось, добавь новую запись с датой и ссылкой на старую».
Это наша экстраполяция из аудита Mem0. Проверять такое правило на агентных файлах авторы не пробовали.
Экстраполяция: проверка перед внедрением системы памяти
Перед покупкой или подключением «умной памяти» для чат-бота сравни её с контрольным вариантом: сырые логи + поиск + модель отвечает сама. Возьми 20–30 реальных вопросов из своих диалогов, прогони оба варианта и проверь вручную. Идея прямо следует из вывода авторов: сложная память должна доказать, что лучше простой базы. Сама процедура — наша.
Ресурсы
- Статья: Is Complex Agentic Memory Always Needed? Naive RAG Is Stronger Than We Thought
- Код: https://github.com/Litmeb/RAW-RAG
- Авторы: Zhengye Bao, Shengtao Zhang, Haokai Zhang, Shiqi Lou, Muning Wen, Minnan Luo (Xi'an Jiaotong University, Shanghai Jiao Tong University, Zhejiang University, The Chinese University of Hong Kong)
- Бенчмарки: LoCoMo, LongMemEval, MEME, MemoryAgentBench, BEAM-1M
- Сравнивали с: Mem0, MemOS, EverMemOS, MemMachine, EMem, Memora, A-MEM и другими