Размышления о ChatGPT и системах памяти Клода: Что нужно для обеспечения возможности извлечения информации из разговора по требованию

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

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

Такие модели, как ChatGPT и Claude, становятся все более "памятливыми", чем больше мы их используем. Они запоминают предпочтения, адаптируются к долгосрочным целям и поддерживают преемственность между сессиями. В этом смысле они уже функционируют как мини-агенты ИИ. Однако под поверхностью их системы памяти построены на совершенно разных архитектурных предпосылках.

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

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

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

Система памяти ChatGPT

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

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

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

[0] Инструкции системы

[1] Инструкции разработчика

[2] Метаданные сессии (эфемерные)

[3] Память пользователя (долгосрочные факты)

[4] Recent Conversations Summary (прошлые чаты, названия + фрагменты)

[5] Сообщения текущей сессии (этот чат)

[6] Ваше последнее сообщение

Компоненты с [2] по [5] образуют эффективную память системы, каждый из которых выполняет свою роль.

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

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

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

• Информация об устройстве - например, является ли пользователь мобильным или настольным компьютером.

• Атрибуты аккаунта - например, уровень подписки (например, ChatGPT Go), возраст аккаунта и общая частота использования.

• Поведенческие метрики - в том числе активные дни за последние 1, 7 и 30 дней, средняя длина разговора и распределение использования модели (например, 49 % запросов обрабатываются GPT-5).

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

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

Эта память может обновляться двумя способами:

• Явные обновления происходят, когда пользователи напрямую управляют памятью с помощью инструкций типа "запомнить это" или "удалить это из памяти".

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

Сводка последних разговоров

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

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

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

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

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

Система памяти в Claude

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

Контекст подсказок в Claude структурирован следующим образом:

[0] Системная подсказка (статические инструкции)

[1] Воспоминания пользователя

[2] История разговора

[3] Текущее сообщение

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

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

В Claude пользовательские воспоминания образуют долгосрочный контекстный слой, аналогичный по назначению пользовательской памяти ChatGPT, но с большим акцентом на автоматическое, фоновое обновление. Эти воспоминания хранятся в структурированном формате (обернутом в теги в стиле XML) и предназначены для постепенного развития с течением времени при минимальном вмешательстве пользователя.

Claude поддерживает два пути обновления:

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

• Явное обновление - пользователи могут напрямую управлять памятью с помощью таких команд, как "запомнить это" или "удалить это", которые выполняются с помощью специального инструмента memory_user_edits.

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

История разговоров

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

Компонент	Назначение	Как используется
Скользящее окно (текущий разговор)	Хранит полную историю сообщений текущего разговора (не сводку), аналогично контексту сессии в ChatGPT.	Инжектируется автоматически. Лимит токенов ~190K; старые сообщения удаляются по достижении лимита
conversation_search инструмент	Поиск прошлых бесед по теме или ключевому слову, возвращает ссылки на беседы, заголовки и выдержки из сообщений пользователя/ассистента	Срабатывает, когда модель определяет, что необходимы исторические подробности. Параметры включают query (условия поиска) и max_results (1-10).
recent_chats инструмент	Извлекает недавние разговоры в указанном диапазоне времени (например, "за последние 3 дня"), результаты оформляются так же, как и conversation_search	Срабатывает, когда недавний, скопированный по времени контекст является релевантным. Параметры включают n (количество результатов), sort_order, и временной диапазон.

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

В целом подход Клода к поиску по требованию имеет несколько заметных достоинств:

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

• Более богатый контекст при необходимости: Полученные результаты могут включать выдержки из ответов помощника, в то время как резюме ChatGPT отражают только сообщения пользователя. Это делает Claude более подходящим для случаев, когда требуется более глубокий или точный контекст разговора.

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

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

Ограничения, лежащие в основе поиска по требованию в стиле Клода

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

1. Низкая латентность

В разговорных системах задержка P99 обычно не должна превышать ~20 мс. Задержки, превышающие это значение, сразу же становятся заметными для пользователей. Это не оставляет места для неэффективности: векторный поиск, фильтрация метаданных и ранжирование результатов должны быть тщательно оптимизированы. Узкое место в любой точке может ухудшить весь разговорный опыт.

2. Требования к гибридному поиску

Запросы пользователей часто охватывают множество измерений. Запрос типа "обсуждения RAG за последнюю неделю" сочетает в себе семантическую релевантность и фильтрацию по времени. Если база данных поддерживает только векторный поиск, она может вернуть 1000 семантически схожих результатов, а фильтрация на прикладном уровне сократит их до нескольких, что приведет к потере большей части вычислений. Чтобы быть практичной, база данных должна изначально поддерживать комбинированные векторные и скалярные запросы.

3. Разделение хранения и вычислений

История разговоров демонстрирует четкую модель доступа "горячий-холодный". Недавние разговоры запрашиваются часто, в то время как к старым разговорам обращаются редко. Если бы все векторы хранились в памяти, то для хранения десятков миллионов разговоров потребовались бы сотни гигабайт оперативной памяти - нецелесообразная для масштаба стоимость. Чтобы быть жизнеспособной, система должна поддерживать разделение хранения и вычислений, сохраняя горячие данные в памяти, а холодные - в объектном хранилище, с загрузкой векторов по требованию.

4. Различные шаблоны запросов

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

Вместе эти четыре задачи определяют основные ограничения разговорного поиска. Любая система, стремящаяся реализовать поиск по требованию в стиле Клода, должна решать все эти проблемы согласованно.

Почему Milvus 2.6 хорошо работает для разговорного поиска

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

Гибридный поиск с плотными и разреженными векторами

Milvus 2.6 поддерживает хранение плотных и разреженных векторов в одной коллекции и автоматическое объединение их результатов во время запроса. Плотные векторы (например, 768-мерные вкрапления, генерируемые моделями типа BGE-M3) отражают семантическое сходство, а разреженные векторы (обычно генерируемые BM25) сохраняют точные сигналы ключевых слов.

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

Разделение хранения и вычислений и оптимизация запросов

Milvus 2.6 поддерживает многоуровневое хранение данных двумя способами:

• Горячие данные в памяти, холодные данные в объектном хранилище.

• Индексы в памяти, необработанные векторные данные в объектном хранилище.

При таком дизайне для хранения одного миллиона записей разговоров достаточно 2 ГБ памяти и 8 ГБ объектного хранилища. При правильной настройке задержка P99 может оставаться ниже 20 мс даже при включенном разделении хранения и вычислений.

Измельчение JSON и быстрая скалярная фильтрация

В Milvus 2.6 по умолчанию включена функция JSON Shredding, сглаживающая вложенные поля JSON в столбчатое хранилище. Это повышает производительность скалярной фильтрации на 3-5×, согласно официальным бенчмаркам (реальный прирост зависит от шаблона запроса).

Разговорный поиск часто требует фильтрации по метаданным, таким как идентификатор пользователя, идентификатор сессии или временной диапазон. С помощью JSON Shredding запросы типа "все разговоры пользователя A за последнюю неделю" можно выполнять непосредственно по столбцовым индексам, без многократного разбора полных JSON-блобов.

Управление с открытым исходным кодом и операционная гибкость

Будучи системой с открытым исходным кодом, Milvus предлагает такой уровень архитектурного и операционного контроля, которого нет у закрытых решений типа "черный ящик". Команды могут настраивать параметры индексов, применять стратегии ярусного размещения данных и настраивать распределенные развертывания в соответствии с рабочими нагрузками.

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

Почему ChatGPT и Claude пошли разными путями

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

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

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

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

В конечном итоге выбор архитектуры зависит от того, что позволяет инфраструктура.

Заключение

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

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

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

У вас есть вопросы или вы хотите получить подробную информацию о любой функции последней версии Milvus? Присоединяйтесь к нашему каналу Discord или создавайте проблемы на GitHub. Вы также можете заказать 20-минутный индивидуальный сеанс, чтобы получить знания, рекомендации и ответы на свои вопросы в Milvus Office Hours.