AI エージェントのメモリOS：すべての階層移行を監査する

AI エージェントのためのメモリOSは,オペレーターが同じユーザーとアシスタントの範囲でストレージ,更新,リクエスト,生成を通じて1つのメモリバージョンを追跡できる場合にのみ健全である. 一貫した回答は有用な結果であるが,以前のすべての移行が実行された証拠ではない. したがって,実用的なデフォルトは単純です. それぞれの境界線に内容のない配列証明書を添付します. メモリコンテンツをホストに保存する. 安定識別子,範囲,ソースバージョン,目的地層,タイムスタンプ,移行状態,生成に使用されたバージョンのみを記録する. 境界線が欠けているか矛盾している場合は,緑の代わりに waiting , at risk , stale ,または uncertain を報告する. この規則は,検索クエリ Z の特定のアーキテクチャにとって重要です. MemoryOS紙では,3つの貯蔵層と4つの機能モジュールが定義されています. また,その実施により,回答品質基準が特定できない狭い失敗窓が明らかになります. MemoryOSが示すこと MemoryOS紙は4つのモジュールを記述する. 1. Storage は短期記憶 (STM),中期記憶 (MTM) と長期個人記憶 (LPM) を組織します. 2. Updating は, STMから MTMに対話ページを移動し,その後, MTMからより長生きしたプロファイルまたは知識資料を抽出します. 3. Retrieval は,レベルから関連する材料を選択します. 4. Generation は,現在の文脈と回収された文脈から応答を構築します. この論文は 階層間の移動について 異常に具体的です STM to MTMの更新は,対話チェーン FIFOプロセスを使用する. MTM to LPMの更新は,熱ベースの選択を伴うセグメントされたページを使用します. 観測可能な移行境界線を定義するのに十分な構造です 記憶を片目のないデータベースとして扱う代わりに. 平均49.11%の改善を報告しています. F1 そして46.18% BLEU 1 基線を超えて LoCoMo と GPT 4o mini. これは著者の基準結果です この監査のために LoCoMo を再起動しませんでした さらに重要なのは 対応の正確性と一貫性は 運用の整体性とは異なる質問に答えることです 高いスコアでは: 避難前にSTMの記録が持続的に存在していた. MTMの目的地が源が消える前に約束された. 同じユーザとアシスタントの範囲がすべての移行に生き残った. 最新の予想されたバージョンを返却した. このバージョンによって 最終世代が 生まれました 紙の架構が境界線を支える. オペレーターはまだ証跡が必要です 目的地へのコミットメントの前にリスク間隔が表示されます プロジェクトを 587ed7755c7aed179965792830ff1b5ad9a6fa92 で確認した 鍵付け:リポジトリがアクティブであり,ソースバージョンなしの運用結論は次の変更後に曖昧になります. 現在の add memory 経路は,短期デッキが満員かどうか確認し,別の項目を追加する前にプロモーションを実行します. ソースはこれを明示的に,静かなデック自動排除 ( memoryos.py ,行 226244) を防ぐための修正として標識する. これは有益な保護手段ですが 昇進は取引的ではありません 昇進の順序は重要です 1. process short term to mid term は pop oldest と呼び STM が満員 ( updater.py ,ライン 100105) である. 2. pop oldest は記録を削除し,すぐにより短いSTMデック ( short term.py ,行 3337) を保存します. 3. LLMがサポートする連続性と概要関数を更新器が呼び出す. 4. MTMの挿入と最終保存は後に起こります ( updater.py ,行 130207). この制御流は リスク源間隔を生成します STMの保存後,プロセスが終了するか,下流操作が失敗した場合, MTMのコミットメントの前に,オペレーターは完成したプロモーション証明書を持っていない. これは源から発生した故障ウィンドウであり,MemoryOSの展開ごとにデータが失われるという主張ではありません. 適切な健康状態は,目的地証跡が存在するまで,または源が回収可能であることを示すまで,単に緑色ではありません. 2つ目の 狭い連続性境界線があります last evicted page for continuity はメモリ内の None 値として開始され,次のパッチに転送され,処理後に更新されます ( updater.py ,行 35及び 115158). 処理を再起動すると その特定の転送暗示がリセットされます 他のMTM類似性論理は,材料を再接続する可能性があるため,これは完全な連続性損失の証明ではない. 移行証跡に前のページまたはソースバージョンを記録する理由であり,プロセスがそれを覚えていると仮定する代わりに. すべてのレベルで1つのコンテンツフリー証跡を使用する 証跡には 提示,回答,概要,埋め込み,または個人情報は必要ありません. 最小のイベントは こんな感じで 各ステージで6つのフィールドを運ぶ runId は,コンテンツを明らかにせずに 1 つのストレージ トゥ ジェネレーション 試みを追加します. userScope と assistantScope は,横断賃貸者または共有助手によるエラーを検出します. version は,期待されるメモリ状態を識別する. sourceVersion は,実装またはアダプター契約をピンします. status は started , waiting , committed , verified ,および失敗した作業を分離します. atUtc は 検証者に 古い証拠が 切れるようにします MemoryOSは既にユーザー専用の短期,中期,長期ファイルと,アシスタント専用の独立した長期ファイル ( memoryos.py ,ライン 7178) を作成している. 証跡には両方の次元が保存されるべきです なぜなら"正しいユーザー,間違った共有アシスタント"は依然として範囲紛争であるからです 発電については, dependsOnVersion と outcomeReceipt を追加する. dependsOnVersion は,どのメモリバージョンが最終プロンプトに入ってきたかを表示します. outcomeReceipt は,可能な限り,決定的な結果チェックを特定する必要があります. ファイルハッシュ,行識別子,試験結果,目的地検索,または意図された作業の存在の他の証明. 記録を厳格なものにするためだけに 敏感な会話内容を 混ぜ合わせるわけにはいきません 緑に信頼する前に不都合な状態を再現する コンテンツのない8つのケースを 構築し実行しました 分類者は,予想される8つの状態をすべて返した. ケース 証拠 州 完全な血統 範囲,バージョン,新鮮さ,レベルコミット,取得,および生成証跡合意 healthy 生産能力の限界に達していない STMは耐久性があり,宣言された待機ウィンドウは開いている. waiting STMは削除され,MTMはコミットされていない 目的地証明前に源が消えた source at risk STMは保持され,プロモーションイベントはありません 予想された MTM 移行は現れませんでした promotion missing プロモーション中にユーザー変更 あるイベントは別の範囲に属します scope conflict 復旧返済 v21 ,予想される v22 記憶は存在しますが 記憶は時代遅れです stale retrieval 流暢な対応,依存の証跡なし 確認された血統なしの完成した世代 generation unverified 実施バージョンはありません 証拠は安全に解釈できない uncertain 重要な違いは waiting と missing です. STMの記録は,文書化された容量の限界に達していないのに持続可能である. 目的地へのコミットメントがない 削除されたソースは待機していません 危険にさらされています タイムスタンプとソース プレゼンスフィールドは,その違いを検査できる. 後の成功は,以前の紛争を隠すことはできないように,明示的な優先順位を使用します. この命令は意図的に保守的なものです 範囲紛争は 成功した対応を上回ります 源リスクは後の活動よりも大きい. 時代遅れの回復は 流暢な世代によって 償われない. 失われた証拠は 健康な証拠に 変換されるよりも 不確実です 証跡を操作ゲートに変換する 個人的な内容や制作内容を含まない カナリーメモリから始めましょう ランダムな識別子と予想されたバージョンを 与え リアルなストレージ プロモーション 検索 生成経路を練習します 採用前またはメモリシステムのアップグレード後: 1. P実装中. パッケージバージョンまたはリポジトリコンビニーを記録し,容量,熱量,類似性,または取得制限を変更する構成を記録する. 2. 試用範囲分離. 2 つのユーザー スコープと,適用する場合, 2 つのアシスタント スコープを実行します. 意図的に各クエリを横切って 間違った経路で検索する必要はありません. 3. 容量移行を強める. 設定された境界まで STM を記入する. すべてのソース削除に MTM コミットが一致していることを確認する. 4. ダウンバックを練習する. マルチサマー輸出が利用できないとき,更新機には一般的なダウンバックがあります. 劣化した経路を標識し,落後完了を正常な品質とみなすのではなく,回収を別々に確認する. 5. バッチ間の再起動. プロセスの再起動後連続性をチェックする. 6. Expire証跡. 昨日のプロモーションは,現在のプロセス,インデックス,ファイルが現在健全であることを証明していない. 7. 結果を確認する. 復元成功はメモリが返還されたことを示しています. 代理人が正しいバージョンを使用したとか 意図された任務を完了したとか 更新が既に部分的にコミットしている場合,リスク源のプロモーションを自動的に再試してはならない. まず, runId とバージョンによって源と目的地を調整する. 盲目の再現は 不確実性を 複製されたページや 長期間の矛盾した事実に変えることができます この証跡は 移行系,範囲,新鮮さ,決定的な結果チェックを証明します LLMが作成した要約が意味的に正しいことを証明するものではありません. これは別々の評価や 影響の高い個人的な事実に対する 人間のレビューや 特定課題の決定的な比較が必要です Sidewispの健康境界線 この監査は Sidewispのメモリとコンテキスト健康モデルに適合します:欠けている読み書き,不可能な持続性,時代遅れの同期化,予期しないリセット,失われた決定は緑のプロセスから推論するよりも目に見えるものとする. Sidewisp は現在プライベートプレビュー段階です。 公開サイトと記事システムはライブで,生産代理の健康収集,実行時間アダプター,および復旧実行は一般的に送付されません. 上記の証跡は,現在実装できるオペレーターパターンであり, Sidewisp が現在 MemoryOS を監視しているという主張ではありません. 解決された規則は厳格だが使用可能である:同じ範囲のバージョンが持続的に保存され,促進され,取得され,使用され,検証された場合にのみメモリシステムに信頼する. 流暢 な 答え は 励まし に なり ます. 欠落した証跡を置き換えることはできません