2026年5月 · 読了時間 10 分 · Fran Olivares、OlivaresAI 創業者
永続メモリーストア自体は何もしません。ストアはクエリされ、スコアリングされ、次のユーザーメッセージが届く前にモデルのコンテキストウィンドウに収まるシステムプロンプトに形作られる必要があります。そのステップ — コンテキスト構築 — が「メモリーデータベースがある」と「AI が覚えている」の違いです。本ガイドは /docs/context-assembly の技術リファレンスの長尺版コンパニオンで、パイプラインのすべての段階、Alma がデフォルトで使用する数値、調整可能なトレードオフを解説します。
モデルはプロンプトにあるものしか見ないからです。1 万エントリーのメモリーストアは、何かがこのターンに適切な 30 を選択しない限り、モデルには見えません。選択が誤っていれば、モデルは関連する事実を見逃して一般的な回答を生成します。選択が広すぎれば、プロンプトはコンテキストウィンドウを超えるか、ノイズにトークンを浪費します。アセンブリはゲートキーパーです — ユーザーが決して見ない静かなステップですが、「AI が覚えている」という感覚全体がその品質に依存しています。
アセンブリは厳しいレイテンシー予算にも当たります。ユーザーは待っています。約 100 ms を超えると、モデルトークンが 1 つもストリームされる前から遅く感じ始めます。これがアセンブリがフルスキャンではなくインデックス検索に依存する理由、スコアリングが LLM 呼び出しではなく重み付き和である理由、ティアごとのトークン予算が動的に交渉されるのではなく事前に計算される理由です。
3 つのメモリーレイヤー(memories、episodes、procedures)すべてにわたるハイブリッド検索を、キーワードとセマンティックのシグナルの両方を使用して行います。ユーザーのクエリはストアをインデックスしたのと同じモデル(Alma のデフォルト構成では bge-m3 1024-dim)で埋め込まれ、その埋め込みはベクトルインデックスに対して実行され、セマンティックに類似したエントリーが浮上します。並列に、キーワード検索がリレーショナルインデックスに当たり、セマンティック検索が時々見逃す完全一致(固有名詞、コード識別子、まれな技術用語)を捉えます。
両方の結果セットはマージされ、重複排除され、候補予算で上限を設けられます(デフォルトはレイヤーあたり 100 — 基盤となるベクトルインデックスがクエリあたりサポートする最大値)。候補プールはスコアリングに流れ込むものです。このステージを過ぎてから、検索が浮上させなかったエントリーを救うものはありません。
5 つの信号、本番スコアリング関数では次のように重み付けされます:
重みは意図的に調整されています: 関連性が支配的ですが、関連性が同点になるとき(密度の高いメモリーストアではよく起こります)に二次的な信号が重要です。重みはコードベース内の不可侵な不変量です — 変更には A/B ベンチマークが必要です。「AI が正しいことを覚えていたか」というユーザーが感じる品質はこの正確なミックスに依存するからです。
各ティア(memories、episodes、procedures、Soul ブロック)には独自のトークン予算があります。デフォルト: memories 約 2 K トークン、episodes 約 1 K、procedures 約 500、Soul ブロック約 500。合計約 4 K — どんな現代のモデルのコンテキストウィンドウより十分に少なく、キャッシュフレンドリーに保つのに十分小さい。各ティア内で、スコア付きエントリーは予算に達するまでランク順に追加されます。
予算は 2 つの理由で存在します。第一に、モデルの実効コンテキストは、特定の密度を超えて詰め込むと縮みます — 100K トークンのプロンプトの底にある関連物は事実上アテンションパターンに見えません。第二に、プロンプトキャッシングはキャッシュされた接頭辞が安定している場合にのみ機能します。低信号のメモリーでプロンプトを膨らませるとキャッシュが破棄され、すべてのターンが満額のトークンを支払うことになります。タイトな予算は品質と経済性の両方を整えます。
5 つのセクションを持つ構造化されたシステムプロンプト(この順序): identity(XML としてレンダリングされたアクティブな Soul ブロック)、preferences(preferences としてフラグ付けされた重要度の高いメモリーエントリー)、関連する事実(このクエリのトップスコアメモリー)、最近のコンテキスト(トップスコアエピソード)、ワークフロー(トップスコア手順)。構造は重要です: identity を上に置くと完全なアテンションを得られ、ワークフローを下に置くと、モデルがクエリを手順的だと決めた場合にのみ参照されます。
ユーザーメッセージは次に次のターンとして追加されます。モデルは構築されたプロンプト + ユーザーメッセージを受け取り、応答を生成します。ユーザーの視点からは、AI はただ答えただけです。下では、アセンブリが何千ものメモリーレコードを静かに参照し、モデルに適切な 30 を示しました。
Alma の本番デプロイメントでは、エンドツーエンドの構築レイテンシーは典型的なユーザー(数百のメモリー、12 のエピソード)で 30 ~ 80 ms の範囲です。ベクトル検索が支配的(約 20 ~ 40 ms)、キーワード検索は並列で実行(約 5 ~ 10 ms)、スコアリングは 1 桁 ms、プロンプト構築は本質的に無料です。候補上限とティア予算により、ストアが成長しても作業が制限されるため、数千のメモリーを持つユーザーでも 100 ms の目標は快適な余裕を持って満たされます。
スコアリング前に、候補プール全体の矛盾検出パスが、セマンティックに矛盾する 0.75 ~ 0.92 の類似度範囲のペアにフラグを立てます。新しいエントリーがデフォルトで勝ち、古いものは置き換えられたとマークされ、このターンの候補セット(および次の統合パスでグローバルに)から削除されます。これにより、モデルが「あなたは X と言った」と「あなたは not-X と言った」を同時に受け取り、ユーザーが決して合意していない統合を即興することを防ぎます。
完全なライフサイクル(重複排除、置き換え、減衰)は 永続メモリー完全ガイド に記載されています。アセンブリはそれらのライフサイクル決定がクエリ時に現れる場所に過ぎません。
アーキテクチャ的には類似(両方とも取得し、ランク付けし、プロンプトに注入する)していますが、コーパスとライフサイクルが異なります。RAG は一度作成され、スケジュールで再インデックスされる外部ドキュメントコーパスから取得します。エントリーは通常進化しません。メモリーアセンブリはユーザー自身の継続的に成長するストアから取得し、エントリーは矛盾し、マージし、減衰します。スコアリングの重みも異なります — RAG はほとんど類似度とドキュメントの権威でランク付けします。メモリーアセンブリは重要性、新しさ、頻度を重み付けします。それらの信号はストアが個人的なときに重要だからです。詳細な比較は 永続メモリー vs RAG を参照してください。
はい。POST /api/v1/context/assemble エンドポイントは、ティアごとの予算、最小スコアしきい値、候補上限、カテゴリータグのブースト重み(PM エージェントは decisions をブースト、ライターのエージェントはボイスルールをブーストできます)のオーバーライドを受け入れます。ほとんどのチームはデフォルトのままです — そのまま使えるように調整されています — が、特殊なバーティカル向けにレバーが存在します。
alma.olivares.ai で始め、関心のあるプロジェクトについて 20 ~ 30 のメモリーを埋めて、チャットを開始してください。新しい会話におけるモデルの最初の応答は、メモリーストアから特定の事実を参照します — それがアセンブリで、ユーザー向けチャットの背後に隠れています。直接統合する開発者向け: REST API は生の構築済みプロンプトを公開するので、各クエリで何が選択されたかを正確に検査できます。
関連する読み物: コンテキスト構築 技術リファレンス · 3 層メモリーアーキテクチャ · AI のための永続メモリー: 2026 年完全ガイド · 永続メモリー vs RAG · Soul Engine の解説。