• Manusプロジェクトの立ち上げ当初、オープンソースの基盤を使用してエンドツーエンドのエージェントモデルをトレーニングするか、フロンティアモデルのインコンテキスト学習能力に基づいてエージェントを構築するかという重要な決断に直面しました。
• 過去のNLPの時代、BERTなどのモデルは新しいタスクに移行する前にファインチューニングと評価が必要であり、このプロセスには数週間かかることもありました。このような遅いフィードバックループは、特に製品市場適合性（PMF）以前の急速に変化するアプリケーションにとっては致命的であるという苦い経験があったため、Manusはコンテキストエンジニアリングに賭けることを選択しました。これにより、改善を数時間で出荷できるようになり、製品を基盤となるモデルから独立させることができました。
• しかし、コンテキストエンジニアリングは決して単純なものではありませんでした。それは実験科学であり、より良いコンテキストの形成方法を発見するたびに、エージェントフレームワークを4回も再構築しました。このアーキテクチャ探索、プロンプト調整、経験的推測といった手動のプロセスを、彼らは「確率的卒業降下（Stochastic Graduate Descent）」と呼んでいます。

Design Around the KV-Cache（KV-キャッシュを中心に設計する）

• エージェントの動作の中では、出力（通常は構造化された関数呼び出し）が比較的短いにもかかわらず、コンテキストがステップごとに増加する。
• Manusでは、平均的な入力対出力のトークン比率は約100:1にも。

• 同一のプレフィックスを持つコンテキストはKV-キャッシュの恩恵を受けることができ、これにより、初回トークンまでの時間（TTFT）と推論コストが大幅に削減される。

• たとえば　Claude Sonnetでは、キャッシュされた入力トークンは0.30 USD/MTokであるのに対し、キャッシュされていないトークンは3 USD/MTokと、10倍の差がある。

• KV-キャッシュヒット率を向上させるための重要な実践方法には以下があります：
1. プロンプトプレフィックスを安定させる: LLMの自己回帰的な性質上、わずか1トークンの違いでもキャッシュが無効になる可能性があります。システムプロンプトの冒頭にタイムスタンプ（特に秒単位の精度）を含めることは、キャッシュヒット率を低下させる一般的な間違いです。
2. コンテキストを追記専用にする: 以前のアクションや観測を修正することを避けてください。シリアライゼーションが決定論的であることを確認することが重要です。多くのプログラミング言語やライブラリはJSONオブジェクトのシリアライゼーションにおいて安定したキー順序を保証しないため、これが原因でキャッシュが静かに破損することがあります。
3. 必要に応じてキャッシュブレークポイントを明示的にマークする: 一部のモデルプロバイダーや推論フレームワークは自動的な増分プレフィックスキャッシュをサポートしていないため、コンテキストに手動でキャッシュブレークポイントを挿入する必要があります。ブレークポイントを設定する際は、キャッシュの有効期限を考慮し、少なくともシステムプロンプトの終わりまでを含めるようにしてください。また、vLLMのようなフレームワークを使用してモデルを自己ホストしている場合は、プレフィックス/プロンプトキャッシュが有効になっていること、およびセッションIDなどの技術を使用して分散ワーカー間でリクエストが一貫してルーティングされるようにしてください。

Mask, Don't Remove（削除ではなくマスクする）

• Auto: モデルが関数を呼び出すかどうかを選択できる。

• Required: モデルが関数を呼び出す必要があるが、選択は制約されない。

• Specified: モデルが特定のサブセットから関数を呼び出す必要がある。

Use the File System as Context（ファイルシステムをコンテキストとして使用する）

Manipulate Attention Through Recitation（繰り返しでアテンションを操作する）

Keep the Wrong Stuff In（失敗をそのままにする）

Don't Get Few-Shotted（フューショットで固定化されない）

• LLMのservingで使われているテクニックを体系的に紹介している記事

• バッチ推論
• Continuous Batching
• 1つ前のバッチ処理がすべて終わってから次のバッチを開始するのではなく、バッチに空きが出るたびに新しいリクエストを割り当てていく

• KVキャッシュマネジメント
• リクエストそれぞれに最大コンテキスト長までKVキャッシュ用のメモリを確保するのは冗長
• PagedAttention



• 固定サイズの物理バッファを用意し、リクエストが終了したタイミングで解放する
• Prefixキャッシュ



• プロンプトのprefixが共通であればそれを使い回すようなキャッシング
• 例: RadixAttention

• アルゴリズムの工夫
• モデルの計算を簡略化して効率改善する
• 量子化
• Weight-only quantization: 重みパラメータのみ量子化
• 重みが小さくなりmemory-boundの領域で計算効率が上がる。小さなバッチサイズで推論をする際に有効
• Weight-activation quantization: 重みパラメータと入力値（activation）両方を量子化
• 行列計算が低ビットになり、Tensor Coreなどの低ビット計算に最適化されたハードウェアが利用可能。バッチサイズが大きくcompute-boundなケースでも推論のスループットを高められる
• KVキャッシュのスパース化
• 長系列に対応しメモリ消費を抑えるため、KVキャッシュのうち重要なものだけを残しそれ以外は捨てるようにする
• StreamingLLM: 最初の数トークンのKVキャッシュは常に保持しておくようにする（文頭のトークンは人間的には意味がなくてもLLM的には重要=attentionスコアが高くなることが多いというヒューリスティックに基づいている）
• パラメータのスパース化
• Wanda: 重みと対応するactivationの値の積の絶対値が小さい（=出力に与える影響が小さい）ものをプルーニングし、推論効率を上げる

• 投機的デコーディング（Speculative Decoding）
• 以前の勉強会で紹介された、小さいLLMを使って大きいLLMのトークン生成を高速化する手法
• 構造的デコーディング（Structured Decoding）
• LLMの生成する文章を特定のフォーマットに制御する。生成時のlogitsを操作し、次のトークンが確定する場合は推論のサイクルを減らせる
• マルチモーダル

• モデルアーキテクチャの工夫



• MQA, GQA, MLA
• Multi-Head Attention: 全てのheadにKey, Valueの別のheadがある
• Multi-Query Attention (MQA): Key, Valueのheadは1つのみ
• Grouped-Query Attention (GQA): Key, Valueのheadはグループごとに1つ
• 最近のLLMはほとんどこれ
• Multi-head Latent Attention (MLA): Key, Valueの値を低ランク行列に圧縮

• その他様々な手法が紹介されているので、元ブログをぜひ！

• LMCacheはLLMの推論エンジン拡張で、TTFT（最初のトークン応答時間）を短縮し、スループットを向上

• 再利用テキストのKVキャッシュをGPU・CPU・ローカルディスクに保存し、インスタンス間で再利用可能

• vLLMと組み合わせることで、QAやRAGなどの用途で3〜10倍の遅延削減とGPU節約が可能

複雑なプロンプトを与えたときの課題

• 入力長の限界: LLMには入力可能な文章量に制限があるため、その中で解決できないと、それ以上何もできなくなってしまいます。

• 認識の限界: 複数の指示をLLMに任せると"Lost in the Middle"などの問題などにより解決すべき問題を見失うことがあります。

コンテキストエンジニアリングでどう解決するか

• 書き出し: 重要な情報を外部に保管して再利用可能にする

• 選択: 必要なコンテキストだけを取得して、余計な情報を持たない

• 圧縮: コンテキストを厳選して、密度の高い情報にする

• 分割: 複雑な問題を分解して、独立した扱いやすい問題にする

• 出力の内容を指定して、情報が散漫にならないようにする

• RAGと組み合わせて、効率のよい検索と組み合わせる

• 単純にデータ量を制限して古いデータを破棄する

• メモ書き、記憶の読み込み

• Toolの選択

• 情報の検索（RAGやWeb検索）

• 「MemGPT」が主要な評価指標として確立した「Deep Memory Retrieval (DMR)」ベンチマークにおいて、94.8%というMemGPTの93.4%を上回る優れた性能を示した。

• さらに、より包括的で挑戦的な「LongMemEval」ベンチマークでも、精度が最大18.5%向上し、同時に応答遅延がベースライン実装と比較して90%削減された。

提案手法zep(Graphiti)の特徴

• 各サブグラフの役割と貢献
• エピソードサブグラフ
• 役割: 生の入力データ（メッセージ、テキスト、JSONなど）を非可逆的に保存し、時間的な順序を維持する。セマンティックエンティティや関係性を抽出する際の基盤となる。
• 寄与: 正確な過去のコンテキスト提供: 過去の会話や入力内容を、そのニュアンスや具体的な表現を含めて正確に参照できる。
• 時間的な推論の基礎: 特定の時点での出来事や発言を正確に特定し、時間的な順序に基づいた推論を可能にする。

• セマンティックエンティティサブグラフ
• 役割: エピソードサブグラフから抽出されたエンティティ（人、物、場所、概念など）と、それらの間の関係性（ファクト）を構造化された形で表現する。
• 寄与: 構造化された知識の提供: LLMが生のテキストを解析してエンティティや関係性を特定する手間を省き、整理された形で知識を提供する。
• 複雑な事実の検索と推論: 特定のエンティティに関する複数の事実や、エンティティ間の複雑な関係性に基づいて、より高度な推論を可能にする。
• 幻覚の抑制: 抽出された事実に基づくコンテキストを提供することで、LLMが事実と異なる情報を生成する「幻覚」を抑制する。

• コミュニティサブグラフ
• 役割: セマンティックエンティティのクラスター（コミュニティ）を形成し、これらのクラスターの高レベルな要約を提供する。ナレッジグラフ全体の広範な、相互接続された視点を提供する。
• 寄与: 高レベルな概念理解: 広範なトピックやドメインに関する概要をLLMに提供し、質問が具体的な事実を問うものでない場合でも、関連性の高い広範なコンテキストを構築できる。
• 検索空間の効率化: 特定のコミュニティに焦点を当てることで、ナレッジグラフ全体を検索する代わりに、関連性の高い情報グループに絞って検索できるため、情報取得の効率が向上する。
• 大規模なデータの要約とパターン認識: 個別のエンティティやファクトに深入りすることなく、全体的な傾向や頻繁に議論されるテーマを把握し、LLMがより抽象的なレベルでの要約や分析を行うことをサポートする。

• コサイン類似度検索、Okapi BM25全文検索、および幅優先探索の3つの検索を採用

• Reciprocal Rank Fusion (RRF) や Maximal Marginal Relevance (MMR) などの既存のリランキングアプローチをサポートしている。

• さらに、Zepは、会話内でのエンティティまたは事実の言及頻度に基づいて結果を優先するグラフベースのエピソード言及リランカーを実装しており、頻繁に参照される情報にアクセスしやすくなるシステムを実現