Операционная система памяти AI-агента: аудит каждого уровня перехода

Операционная система памяти для агента ИИ работоспособна только тогда, когда оператор может отслеживать одну версию памяти посредством хранения, обновления, извлечения и генерации под одной и той же областью действия пользователя и помощника. Последовательный ответ — это полезный результат, но он не является свидетельством того, что все предыдущие переходы были совершены. Поэтому практический вариант по умолчанию прост: прикрепите к каждой границе квитанцию ​​о происхождении без содержания. Сохраняйте содержимое памяти на хосте. Записывайте только стабильные идентификаторы, область действия, исходную версию, целевой уровень, временные метки, статус перехода и версию, использованную для создания. Если граница отсутствует или противоречива, сообщите о waiting , at risk , stale или uncertain вместо зеленого цвета. Это правило имеет значение для конкретной архитектуры поискового запроса операционная система искусственного интеллекта . В документе MemoryOS определены три уровня хранения и четыре функциональных модуля. Его реализация также предоставляет узкое окно ошибок, которое не может определить тест качества ответа. Что устанавливает MemoryOS Статья о памятиOS описывает четыре модуля: 1. Хранение организует кратковременную память (STM), среднесрочную память (MTM) и долговременную личную память (LPM). 2. Обновление перемещает страницы диалога из STM в MTM, а затем извлекает из MTM долгоживущий профиль или материал знаний. 3. Извлечение выбирает соответствующий материал на уровнях. 4. Генерация формирует ответ на основе текущего и полученного контекста. В документе необычайно конкретно говорится о движении между уровнями. Обновление STM MTM использует процесс FIFO диалоговой цепочки. При обновлении MTM to LPM используются сегментированные страницы с выбором на основе тепла. Этой структуры достаточно, чтобы определить наблюдаемые границы перехода вместо того, чтобы рассматривать «память» как одну непрозрачную базу данных. Авторы сообщают о среднем улучшении на 49,11% в F1 и на 46,18% в BLEU 1 по сравнению с исходными показателями при использовании LoCoMo с GPT 4o mini. Это результаты тестов авторов; Для этого аудита я не запускал LoCoMo повторно. Что еще более важно, правильность и последовательность реагирования отвечают на другой вопрос, а не на оперативную целостность. Высокий балл не доказывает, что: запись СТМ постоянно присутствовала до выселения; пункт назначения MTM, зафиксированный до исчезновения источника; при каждом переходе сохранялась одна и та же область пользователя и помощника; при поиске возвращается самая новая ожидаемая версия; последнее поколение фактически зависело от этой версии. Архитектура газеты определяет границы. Оператору еще нужны квитанции на них. Рискованный интервал появляется перед фиксацией места назначения Я проверил проект в закрепленном коммите 587ed7755c7aed179965792830ff1b5ad9a6fa92 . Закрепление имеет значение: репозиторий активен, и оперативное заключение без исходной версии станет неоднозначным после очередного изменения. Текущий путь add memory проверяет, заполнена ли краткосрочная очередь, и запускает повышение перед добавлением другого элемента. Источник явно называет это исправлением, предотвращающим автоматическое вытеснение из очереди ( memoryos.py , строки 226–244.). Это полезная гарантия, но она не делает продвижение транзакционным. Последовательность продвижения имеет значение: 1. process short term to mid term вызывает pop oldest , пока STM заполнен ( updater.py , строки 100–105.). 2. pop oldest удаляет запись и немедленно сохраняет более короткую деку STM ( short term.py , строки 33–37.). 3. Затем средство обновления вызывает функции непрерывности и сводки, поддерживаемые LLM. 4. Вставка MTM и его окончательное сохранение происходят позже ( updater.py , строки 130–207.). Этот поток управления создает интервал источника риска. Если процесс завершается или неперехваченная нисходящая операция завершается сбоем после сохранения STM, но до фиксации MTM, у оператора нет завершенного доказательства повышения. Это окно сбоя на основе источника, а не утверждение о том, что при каждом развертывании MemoryOS данные теряются. Правильное состояние работоспособности просто не является зеленым до тех пор, пока не появится квитанция назначения или пока не будет показано, что источник остается восстанавливаемым. Есть вторая, более узкая граница непрерывности. last evicted page for continuity начинается как значение None в памяти, переносится в следующий пакет и обновляется после обработки ( updater.py , строки 35 и 115–158.). Перезапуск процесса сбрасывает эту конкретную подсказку о переносе. Другая логика подобия MTM все еще может повторно соединить материал, поэтому это не является доказательством полной потери непрерывности. Это повод записать предыдущую страницу или исходную версию в квитанцию ​​о переходе вместо того, чтобы предполагать, что процесс ее запомнил. Используйте одну квитанцию ​​без содержимого на всех уровнях Квитанция не требует подсказок, ответов, резюме, вложений или личных фактов. Минимальное событие может выглядеть так: Пронесите шесть полей через каждый этап: runId присоединяется к одной попытке преобразования хранилища в генерацию без раскрытия содержимого. userScope и assistantScope выявляют ошибки перекрестного клиента или общего помощника. version идентифицирует ожидаемое состояние памяти. sourceVersion закрепляет контракт реализации или адаптера. status отделяет started , waiting , committed , verified и неудачную работу. atUtc позволяет верификатору истечь срок действия устаревших доказательств. MemoryOS уже создает краткосрочные, среднесрочные и долгосрочные файлы для конкретного пользователя, а также отдельный долгосрочный файл для помощника ( memoryos.py , строки 71–78.). В квитанции должны сохраняться оба измерения, поскольку «правильный пользователь, неправильный общий помощник» по прежнему является конфликтом области действия. Для генерации добавьте dependsOnVersion и outcomeReceipt . dependsOnVersion сообщает, какая версия извлеченной памяти указана в последнем приглашении. outcomeReceipt должен, где это возможно, указывать детерминированную проверку результата: хеш файла, идентификатор строки, результат теста, поиск места назначения или другое доказательство того, что запланированная работа существует. Это не должно быть мешанина конфиденциального содержания разговора просто для того, чтобы запись выглядела строго. Воспроизведите неудобные состояния, прежде чем доверять зеленому Я построил и реализовал восьмикорпусное приспособление без содержания. Классификатор вернул все восемь ожидаемых состояний: Дело Доказательства Государство Полная родословная Область действия, версия, актуальность, фиксации уровня, извлечение и получение генерации согласуются healthy Порог емкости не достигнут STM долговечен и объявленное окно ожидания открыто waiting STM удален, MTM не зафиксирован Источник исчез до доказательства назначения source at risk STM сохранен, рекламных акций нет Ожидаемый переход на МТМ так и не состоялся promotion missing Изменения пользователей во время продвижения Одно событие принадлежит другой области scope conflict Поиск возвращает v21 , ожидается v22 Настоящая память существует, но она устарела stale retrieval Свободный ответ, отсутствие получения зависимости Генерация завершена без подтверждения происхождения generation unverified Нет версии реализации Доказательства не могут быть интерпретированы безопасно uncertain Важное различие между ожиданием и отсутствием . Запись STM, которая остается устойчивой до тех пор, пока не был достигнут документированный порог емкости, не застревает. Удаленный источник без фиксации назначения не ожидает; это находится под угрозой. Поля отметки времени и присутствия источника позволяют проверить эту разницу. Используйте явный приоритет, чтобы более поздний успех не мог скрыть более ранний конфликт: Этот порядок сознательно консервативен. Конфликт по масштабам превосходит успешный ответ. Исходный риск превосходит по значимости более позднюю деятельность. Устаревшее извлечение не компенсируется плавной генерацией. Отсутствующие доказательства остаются неопределенными, а не превращаются в полезные. Превратите квитанцию ​​в рабочие ворота Начните с одной канареечной памяти, не содержащей личного или производственного контента. Присвойте ему случайный идентификатор и ожидаемую версию, а затем реализуйте реальный путь хранения, продвижения, извлечения и генерации. До внедрения или после обновления системы памяти: 1. Закрепите реализацию. Запишите версию пакета или фиксацию репозитория, а также конфигурацию, которая изменяет ограничения емкости, теплоты, сходства или извлечения. 2. Подтвердите изоляцию области. Запустите две области пользователя и, если применимо, две области помощника. Намеренно пересекайте каждый запрос и не требуйте поиска по неправильной полосе. 3. Принудительное изменение мощности. Заполните STM до настроенной границы. Убедитесь, что каждое удаление исходного кода имеет соответствующую фиксацию MTM. 4. Используйте резервный вариант. Средство обновления имеет резервный вариант общего сводного отчета, когда вывод нескольких сводных данных недоступен. Пометьте этот путь как ухудшенный и проверяйте извлечение отдельно вместо того, чтобы рассматривать резервное завершение как нормальное качество. 5. Перезапуск между пакетами. Проверьте непрерывность после перезапуска процесса, поскольку перенос в памяти не является надежным свидетельством. 6. Квитанции об истечении срока действия. Повышение, которое было работоспособным вчера, не означает, что текущий процесс, индекс или файлы работоспособны сейчас. 7. Проверьте результат. Успешное извлечение означает, что воспоминание было возвращено. В нем не говорится, что агент использовал правильную версию или выполнил намеченную задачу. Не повторяйте автоматическое повышение уровня источника риска, если обновление уже частично зафиксировано. Сначала согласуйте источник и место назначения по runId и версии. Слепое воспроизведение может превратить неопределенность в дублированные страницы или противоречивые долгосрочные факты. Ограничение не менее важно: эта квитанция подтверждает происхождение перехода, объем, свежесть и детерминированные проверки результатов. Это не доказывает, что резюме, составленное LLM, семантически правильно. Это требует отдельной оценки, человеческого анализа важных личных фактов или детерминистического сравнения для конкретной задачи. Граница работоспособности Sidewisp Этот аудит соответствует модели работоспособности памяти и контекста Sidewisp: отсутствующие операции чтения или записи, сбой сохранения, устаревшая синхронизация, неожиданные сбросы и потерянные решения должны быть видимыми, а не вытекать из зеленого процесса. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Его общедоступный сайт и система статей работают, а сбор данных о работоспособности производственного агента, адаптеры времени выполнения и выполнение восстановления обычно не поставляются. Приведенная выше квитанция представляет собой шаблон оператора, который вы можете реализовать прямо сейчас; это не утверждение, что Sidewisp в настоящее время отслеживает MemoryOS. Установленное правило является строгим, но применимым: доверяйте системе памяти только в том случае, если одна и та же версия с определенной областью надежно хранится, продвигается, извлекается, используется и проверяется. Беглый ответ может воодушевить. Он не может заменить недостающую квитанцию.