Устаревает ли RAG сейчас, когда появляются такие долгоиграющие агенты, как Claude Cowork?

Claude Cowork - это новая функция агента в приложении Claude Desktop. С точки зрения разработчика, это, по сути, автоматическая программа для выполнения задач, обернутая вокруг модели: она может читать, изменять и генерировать локальные файлы, а также планировать многоэтапные задачи без необходимости вручную запрашивать каждый шаг. Считайте, что это тот же цикл, что и в Claude Code, но выведенный на рабочий стол, а не в терминал.

Ключевая особенность Cowork - способность работать в течение длительного времени без потери состояния. В нем нет обычного таймаута разговора или сброса контекста. Он может продолжать работу, отслеживать промежуточные результаты и повторно использовать предыдущую информацию в разных сессиях. Это создает впечатление "долговременной памяти", хотя механика, лежащая в основе, больше похожа на постоянное состояние задачи + перенос контекста. В любом случае опыт отличается от традиционной модели чата, где все сбрасывается, если вы не создадите свой собственный слой памяти.

Это поднимает два практических вопроса для разработчиков:

1. Если модель уже может запоминать прошлую информацию, то куда в таком случае вписывается RAG или агентский RAG? Будет ли RAG заменен?

2. Если мы хотим иметь локального агента в стиле Cowork, как нам самим реализовать долговременную память?

В остальной части статьи мы подробно рассмотрим эти вопросы и объясним, как векторные базы данных вписываются в этот новый ландшафт "модельной памяти".

Claude Cowork vs. RAG: в чем разница?

Как я уже говорил, Claude Cowork - это агентский режим внутри Claude Desktop, который может читать и записывать локальные файлы, разбивать задачи на более мелкие шаги и продолжать работу без потери состояния. Он поддерживает свой собственный рабочий контекст, поэтому многочасовые задачи не сбрасываются, как обычная сессия чата.

RAG (Retrieval-Augmented Generation) решает другую проблему: предоставляет модели доступ к внешним знаниям. Вы индексируете данные в векторной базе данных, извлекаете соответствующие фрагменты для каждого запроса и передаете их в модель. Эта система широко используется, поскольку она обеспечивает LLM-приложениям форму "долговременной памяти" для документов, журналов, данных о продуктах и т. д.

Если обе системы помогают модели "запоминать", то в чем, собственно, разница?

Как Cowork работает с памятью

Память Cowork работает по принципу "чтение-запись". Агент решает, какая информация из текущей задачи или разговора является актуальной, сохраняет ее в памяти и извлекает позже по мере выполнения задачи. Это позволяет Cowork поддерживать непрерывность длительных рабочих процессов - особенно тех, которые по мере выполнения создают новые промежуточные состояния.

Как RAG и Agentic RAG работают с памятью

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

Современный агентный RAG расширяет этот паттерн. Модель может решать, когда получить информацию, что получить и как ее использовать во время планирования или выполнения рабочего процесса. Такие системы могут выполнять длительные задачи и вызывать инструменты, подобно Cowork. Но даже в агентных RAG уровень поиска остается ориентированным на знания, а не на состояние. Агент извлекает авторитетные факты; он не записывает свое изменяющееся состояние задачи обратно в корпус.

Другой способ взглянуть на это:

• Память Cowork ориентирована на задачи: агент пишет и читает свое собственное развивающееся состояние.

• RAG ориентирована на знания: система извлекает устоявшуюся информацию, на которую должна опираться модель.

Реверс-инжиниринг Claude Cowork: Как он строит долговременную память агента

Cowork получил много шумихи, потому что он справляется с многоэтапными задачами, не забывая постоянно о том, что он делал. С точки зрения разработчика, мне интересно , как он сохраняет состояние в течение таких длительных сессий? Anthropic не опубликовала внутреннюю информацию, но, основываясь на предыдущих экспериментах разработчиков с модулем памяти Клода, мы можем собрать воедино приличную ментальную модель.

Похоже, что Клод использует гибридную систему: постоянный слой долговременной памяти и инструменты извлечения информации по требованию. Вместо того чтобы запихивать полный текст разговора в каждый запрос, Клод выборочно извлекает прошлый контекст только тогда, когда решает, что он уместен. Это позволяет модели поддерживать высокую точность, не расходуя токены каждый раз.

Если разобрать структуру запроса, то она выглядит примерно так:

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

Интересна не сама структура, а то, как модель решает, что обновлять и когда запускать поиск.

Память пользователя: Постоянный слой

Клод хранит долговременную память, которая обновляется с течением времени. И в отличие от более предсказуемой системы памяти ChatGPT, система Клода кажется более "живой". Он хранит воспоминания в блоках, похожих на XML, и обновляет их двумя способами:

• Неявные обновления: Иногда модель просто решает, что что-то является устойчивым предпочтением или фактом, и тихо записывает это в память. Эти обновления не мгновенны; они появляются через несколько ходов, а старые воспоминания могут исчезнуть, если исчезнет связанный с ними разговор.

• Явные обновления: Пользователи могут напрямую изменять память с помощью инструмента memory_user_edits ("запомнить X", "забыть Y"). Эти записи происходят немедленно и больше похожи на операции CRUD.

Claude выполняет фоновую эвристику, чтобы решить, что стоит сохранить, и не ждет явных инструкций.

Поиск разговоров: Часть по требованию

Claude не хранит сводку, как многие системы LLM. Вместо этого у него есть набор функций поиска, которые он может вызывать каждый раз, когда считает, что ему не хватает контекста. Эти вызовы не происходят каждый раз - модель запускает их на основе своих внутренних суждений.

Особо выделяется conversation_search. Когда пользователь говорит что-то неопределенное, например "тот проект в прошлом месяце", Клод часто запускает этот инструмент, чтобы найти соответствующие развороты. Примечательно, что он срабатывает и тогда, когда фраза двусмысленна или написана на другом языке. Это довольно очевидно:

• Какое-то семантическое соответствие (вкрапления).

• Возможно, в сочетании с нормализацией или облегченным переводом

• поиск по ключевым словам для повышения точности.

В общем, это очень похоже на миниатюрную систему RAG, встроенную в инструментарий модели.

Чем поведение поиска Клода отличается от базовых буферов истории

Из тестирования и журналов можно выделить несколько особенностей:

• Извлечение не является автоматическим. Модель сама выбирает, когда ее вызывать. Если она считает, что у нее уже достаточно контекста, она даже не будет беспокоиться.

• Извлеченные фрагменты включают сообщения как пользователя, так и помощника. Это полезно - сохраняется больше нюансов, чем в резюме только для пользователя.

• Использование токенов остается нормальным. Поскольку история не пополняется каждый раз, длительные сессии не приводят к непредсказуемым последствиям.

В целом, это похоже на LLM с расширенным поиском, только поиск происходит в рамках собственного цикла рассуждений модели.

Эта архитектура умна, но не бесплатна:

• Поиск добавляет задержку и больше "движущихся частей" (индексирование, ранжирование, повторное ранжирование).

• Модель иногда неправильно определяет, нужен ли ей контекст, что приводит к классической "забывчивости LLM", даже если данные были доступны.

• Отладка становится сложнее, потому что поведение модели зависит от невидимых триггеров инструментов, а не только от ввода подсказок.

Клод Коворк против Клода Кодекса в работе с долговременной памятью

В отличие от модели Клода, в которой много внимания уделяется извлечению информации, ChatGPT работает с памятью гораздо более структурированным и предсказуемым образом. Вместо того чтобы выполнять семантический поиск или рассматривать старые разговоры как мини-векторное хранилище, ChatGPT вводит память непосредственно в каждую сессию через следующие многоуровневые компоненты:

• Память пользователя

• метаданные сессии

• Сообщения текущей сессии

Память пользователя

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

ChatGPT обновляет этот слой двумя способами:

• Явные обновления: Пользователи могут сказать модели "запомнить это" или "забыть это", и память немедленно изменится. По сути, это CRUD API, который модель раскрывает через естественный язык.

• Неявные обновления: Если модель обнаружит информацию, которая соответствует правилам OpenAI для долгосрочной памяти, например должность или предпочтения, и пользователь не отключил память, она спокойно добавит ее самостоятельно.

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

Метаданные сессии

Метаданные сеанса находятся на противоположном конце спектра. Они недолговечны, непостоянны и вводятся только один раз в начале сеанса. Считайте, что это переменные среды для общения. Сюда входят такие сведения, как:

• на каком устройстве вы находитесь

• состояние учетной записи/подписки

• примерные модели использования (активные дни, распределение моделей, средняя длина разговора).

Эти метаданные помогают модели формировать ответы в соответствии с текущей средой - например, писать более короткие ответы на мобильных устройствах, не загрязняя долгосрочную память.

Сообщения текущей сессии

Это стандартная история со скользящим окном: все сообщения в текущем разговоре до тех пор, пока не будет достигнут лимит маркеров. Когда окно становится слишком большим, старые сообщения автоматически удаляются.

Очень важно, что это вытеснение не затрагивает память пользователя или межсессионные сводки. Уменьшается только локальная история разговора.

Самое большое расхождение с Клодом проявляется в том, как ChatGPT обрабатывает "недавние, но не текущие" разговоры. Claude вызывает поисковый инструмент для извлечения прошлого контекста, если считает его релевантным. ChatGPT этого не делает.

Вместо этого ChatGPT хранит очень легкую межсессионную сводку, которая вставляется в каждый разговор. Несколько ключевых деталей об этом слое:

• Он обобщает только сообщения пользователей, но не сообщения помощников.

• Он хранит очень небольшой набор элементов - примерно 15 - достаточно, чтобы отразить устойчивые темы или интересы.

• В нем нет ни вычислений встраивания, ни ранжирования по сходству, ни вызовов поиска. По сути, это готовый контекст, а не динамический поиск.

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

Проблемы, связанные с возможностью записи в память агента

Когда агент переходит от памяти только для чтения (типичная RAG) к памяти для записи, гдеон может регистрировать действия, решения и предпочтения пользователей, сложность быстро возрастает. Вы больше не просто извлекаете документы; вы поддерживаете растущее состояние, от которого зависит модель.

Система с записываемой памятью должна решить три реальные проблемы:

1. Что запоминать: Агенту нужны правила для принятия решений о том, какие события, предпочтения или наблюдения стоит сохранить. Без этого память либо увеличивается в размерах, либо заполняется шумом.

2. Как хранить и распределять память: Не вся память одинакова. Недавние события, долгосрочные факты и эфемерные заметки нуждаются в разных уровнях хранения, политиках сохранения и стратегиях индексирования.

3. Как писать быстро, не нарушая процесса извлечения: Память должна записываться постоянно, но частые обновления могут ухудшить качество индекса или замедлить запросы, если система не рассчитана на высокопроизводительные вставки.

Задача 1: Что стоит запоминать?

Не все, что делает пользователь, должно оставаться в долговременной памяти. Если кто-то создает временный файл, а через пять минут удаляет его, запись об этом навсегда никому не поможет. В этом и заключается основная трудность: как система решает, что действительно важно?

(1) Распространенные способы определения важности

Команды обычно полагаются на сочетание эвристик:

• Основанные на времени: недавние действия имеют большее значение, чем старые

• На основе частоты: файлы или действия, к которым обращаются неоднократно, более важны

• На основе типа: некоторые объекты по своей сути более важны (например, файлы конфигурации проекта по сравнению с файлами кэша).

(2) Когда правила противоречат друг другу

Эти сигналы часто противоречат друг другу. Файл, созданный на прошлой неделе, но сильно отредактированный сегодня, - что должно победить: возраст или активность? Единого "правильного" ответа не существует, поэтому оценка важности быстро становится беспорядочной.

(3) Как помогают векторные базы данных

Векторные базы данных дают вам механизмы для обеспечения соблюдения правил важности без ручной очистки:

• TTL: Milvus может автоматически удалять данные по истечении заданного времени.

• Распад: старые векторы могут быть понижены в весе, так что они естественным образом исчезают из поиска.

Задача 2: многоуровневое распределение памяти на практике

По мере того как агенты работают дольше, память накапливается. Хранить все в быстром хранилище невозможно, поэтому системе нужен способ разделить память на "горячий" (часто используемый) и "холодный" (редко используемый) уровни.

(1) Решение о том, когда память становится холодной

В этой модели горячая память относится к данным, хранящимся в оперативной памяти для доступа с малым временем ожидания, а холодная память - к данным, перемещенным на диск или в объектное хранилище для снижения стоимости.

Решение о том, когда память становится холодной, может приниматься по-разному. Некоторые системы используют облегченные модели для оценки семантической важности действия или файла на основе его значения и недавнего использования. Другие полагаются на простую логику, основанную на правилах, например перемещение памяти, к которой не обращались в течение 30 дней или которая не появлялась в результатах поиска в течение недели. Пользователи также могут явно отмечать определенные файлы или действия как важные, чтобы они всегда оставались "горячими".

(2) Где хранятся "горячие" и "холодные" воспоминания

После классификации горячая и холодная память хранятся по-разному. Горячая память остается в оперативной памяти и используется для часто используемого содержимого, например контекста активной задачи или последних действий пользователя. Холодная память перемещается на диск или в системы хранения объектов, такие как S3, где доступ к ней медленнее, но стоимость хранения гораздо ниже. Такой компромисс хорошо работает, поскольку холодная память нужна редко и к ней обычно обращаются только для долгосрочного хранения.

(3) Как помогают векторные базы данных

Milvus и Zilliz Cloud поддерживают эту схему, обеспечивая многоуровневое хранение данных в режиме "горячий-холодный" при сохранении единого интерфейса запросов, поэтому часто используемые векторы остаются в памяти, а старые данные автоматически перемещаются в более дешевое хранилище.

Задача 3: Как быстро должна записываться память?

Традиционные системы RAG обычно записывают данные партиями. Индексы перестраиваются в автономном режиме - часто за одну ночь - и становятся доступными для поиска только позже. Такой подход подходит для статичных баз знаний, но не подходит для памяти агентов.

(1) Почему память агента нуждается в записях в реальном времени

Память агента должна фиксировать действия пользователя в момент их совершения. Если действие не будет записано немедленно, то в следующем разговоре может отсутствовать критический контекст. По этой причине системы памяти с возможностью записи требуют записи в реальном времени, а не отложенных, автономных обновлений.

(2) Противоречие между скоростью записи и качеством извлечения информации

Память реального времени требует очень низкой задержки записи. В то же время высокое качество поиска зависит от хорошо построенных индексов, а построение индекса требует времени. Перестраивать индекс при каждой записи слишком дорого, но задержка индексации означает, что вновь записанные данные остаются временно невидимыми для поиска. Этот компромисс находится в центре проектирования памяти с возможностью записи.

(3) Как помогают векторные базы данных

Векторные базы данных решают эту проблему, отделяя запись от индексирования. Общим решением является потоковая запись и инкрементное построение индексов. В примере с Milvus новые данные сначала записываются в буфер в памяти, что позволяет системе эффективно обрабатывать высокочастотные записи. Еще до создания полного индекса буферизованные данные могут быть запрошены в течение нескольких секунд с помощью динамического слияния или приблизительного поиска.

Когда буфер достигает заданного порога, система строит индексы партиями и сохраняет их. Это повышает производительность долгосрочного поиска, не блокируя запись в реальном времени. Разделяя быструю запись и медленное построение индексов, Milvus достигает практического баланса между скоростью записи и качеством поиска, который хорошо подходит для агентской памяти.

Заключение

Cowork дает нам представление о новом классе агентов - персистентных, с состоянием и способных переносить контекст на большие временные отрезки. Но он также дает понять и другое: долговременная память - это только половина картины. Для создания автономных и надежных агентов, готовых к производству, нам все еще нужен структурированный поиск по большим, развивающимся базам знаний.

RAG работает с фактами мира; записываемая память - с внутренним состоянием агента. Векторные базы данных находятся на пересечении, обеспечивая индексацию, гибридный поиск и масштабируемое хранение, которые позволяют обоим слоям работать вместе.

По мере развития агентов, работающих в течение длительного времени, их архитектуры, скорее всего, будут сходиться к этой гибридной конструкции. Cowork - это сильный сигнал того, куда все движется - не к миру без RAG, а к агентам с более богатыми стеками памяти, подкрепленными векторными базами данных.

Если вы хотите изучить эти идеи или получить помощь в создании собственной системы, присоединяйтесь к нашему Slack-каналу, чтобы пообщаться с инженерами Milvus. А для более практического руководства вы всегда можете заказать сеанс Milvus Office Hours .