top of page

SALTはより多くの記憶を取得するが、小規模モデルでは精度が低下する

horizon machinelearningの投稿は、検索をめぐる明確な対立を浮き彫りにした。SALTはメモリ全体のトライを効率的に検索する一方、取得量が多すぎると小規模モデルはハルシネーションを起こすという。

開発者によると、SALTはすべての入力をトライに保存する。トライは共通プレフィックスを共有して重複保存を減らす、木構造のデータ構造だ。その後、テーマ優勢度とCELF選択を用い、取得予算を20パーセントに設定する。これらの実装に関する主張は、独立したレビュー済み評価ではなく、開発者の検索に関する議論に基づく。

このシステムはチャットボットで動作すると報告されているが、現在はエージェントもこのアーキテクチャに加わりつつある。この変化により重要性は増す。複数のモジュールが重複する記憶を取得し、周辺的にしか関係しない事実を繰り返し、何らかの行動を取る前に生成モデルの限られた注意力を消費しかねない。

中心的な問題は、SALTが関連する文を見つけられるかどうかではない。どうやら、見つけすぎるのである。より難しい問いは、もっともらしいが注意をそらす情報を除外しながら、必要な依存関係をすべて保持できる検索ポリシーを設計できるかどうかだ。

これにより、2つの目的が直接対立する。テーマカバレッジは、アクティブなトピックをより広く表現する集合を評価する。エビデンスの精度は、正しい回答や行動を変える情報だけを評価する。小規模モデルでは、後者の目的の方が前者より重要になり得る。

SALTの提案は、記憶の想起を選択問題へと変える

SALTで報告されているボトルネックは、ストレージの処理が成功した後に始まる。効率的にアクセスできても、有用なコンテキストが得られるとは限らないためだ。

投稿によれば、すべての入力はDRAM内のトライに格納される。DRAMはシステムの高速な作業メモリであり、トライは共有プレフィックスを通じてシーケンスを整理する。この設計により、繰り返されるテキストパターンをコンパクトに保存し、迅速に参照できる可能性がある。

開発者は次に、キーワードとテーマ優勢度のシステムを通じて文を取得する。CELF手続きは、20パーセントに設定された予算内で情報を選択する。CELF、すなわちCost-Effective Lazy Forward selectionは、各候補の限界価値を不必要に再計算しないことで、貪欲最適化を高速化する。

魅力的な性質は、収穫逓減にある。新しいテーマをカバーする文は、当初は大きな価値を提供できる。同じテーマをカバーする別の文は、最初の文が選択集合に入った後では、寄与が小さくなるはずだ。

この論理は、多様性とカバレッジが重要な検索に適している。ほぼ重複した項目で埋まる結果集合を抑えつつ、トピックの複数の側面を表示できる。また、可能なすべての部分集合を採点せずに、大規模なメモリ集合を扱いやすくする。

しかし、固定比率は固定された情報需要を表すわけではない。短い会話の20パーセントなら、コンパクトなプロンプトになる可能性がある。大規模で永続的なエージェントメモリの20パーセントでは、小規模モデルが信頼性高く利用できる量を大きく上回る情報が生成され得る。

別の上限が設けられない限り、候補プールの拡大に伴って予算も増える。より多くのモジュールが記憶を書き込むほど、テーマに整合する候補は増殖し得る。セレクタは計算上の効率を維持できても、その出力は言語モデルにとって認知的に高コストになり得る。

この区別が重要なのは、検索には少なくとも3つの別個の段階があるためだ。システムは候補を生成し、それらを順位付けまたは選択し、さらにモデル向けにパッケージ化しなければならない。最初の2段階の高速性は、第3段階の精度を裏付けるものではない。

公開情報には、SALTのテーマ表現、文の境界、重複排除のルール、評価セットがまだ記載されていない。また、20パーセントの予算が文、トークン、保存ノード、あるいは別の単位のどれを測定しているかも明らかにしていない。

こうした詳細は診断を左右する。文数予算はトークン長の大きな差を隠し得る。トークン予算でも、同一の命題の繰り返しを許してしまう可能性がある。トライ内のノード予算は、読みやすいエビデンスにきれいに対応しない場合がある。

報告されているリポジトリの場所であるSALT source codeは、調査中に一貫してアクセスできなかった。したがって、投稿を超えるアーキテクチャ上の詳細は、コードと再現可能なテストが利用可能になるまで暫定的なものとして扱うべきだ。

それでも、何が変わったかは明らかである。SALTはチャットボットの設定から、複数のモジュールにまたがる行動へとメモリ検索が影響するエージェントの設定へ移行しつつある。この移行により、過剰な想起は会話上の煩わしさから、システム全体の信頼性問題へと変わる。

Horizon MachineLearningの注目が過剰なコンテキストに集まった理由

horizon machinelearningでの議論が重要なのは、取得されたすべての文がクエリのテーマを共有していても、関連性がありそうなコンテキストを追加すると精度が低下し得るためだ。

言語モデルは、与えられたすべての情報を同じように有用なものとして扱うわけではない。コンテキストウィンドウは最大入力サイズを定めるが、容量があるからといって信頼できる利用が保証されるわけではない。位置、反復、曖昧さ、タスクの複雑さはすべて、モデルが実際に何に従うかへ影響する。

古典的な長文コンテキスト研究は、複数文書の質問応答とキー・バリュー検索を検証した。研究者らは、求められる答えを変えずに、関連エビデンスが現れる位置を変更した。性能はしばしばU字型の曲線を描き、情報が冒頭または末尾にある場合に有利だった。

ある報告された設定では、関連文書が長いコンテキスト内の不利な位置に置かれると、GPT-3.5-Turboの性能はクローズドブック時の56.1パーセントというベースラインを下回った。研究者らは、追加文書の取得による効果も逓減することを確認した。

オープンドメイン質問応答のケーススタディでは、文書数を20から50に増やしても、結果の改善はごくわずかだった。追加の検索再現率は、それに見合う回答精度の向上にはつながらなかった。生成モデルは、余分な情報をすべて効果的に活用できなかった。

より新しいエビデンスは、この警告をさらに明確にする。2025年のコンテキスト長研究では、検索自体が完全であっても、長い入力が性能を損なう可能性が示された。この結果は、チームがしばしば混同する2つの失敗要因を分けている。

1つ目は検索エラーであり、システムが欠落した、誤解を招く、または不完全なエビデンスを選ぶ場合に起きる。2つ目は利用エラーであり、モデルが十分なエビデンスを受け取っても、それを信頼性高く推論に用いられない場合に起きる。前者を減らしても、後者が自動的に解決するわけではない。

この区別は、検索ダッシュボードではテーマカバレッジが良好に見える一方で、回答が悪化し得る理由を説明する。文は正しいテーマに属していても、現在の要求を解決する助けにならないことがある。また、古い値、例外、あるいは近接する概念を持ち込む可能性もある。

ソフトウェアデプロイを準備するエージェントを考えてみよう。デプロイポリシー、過去のインシデント、テスト、権限、顧客への影響に関する記憶は、いずれも広いテーマには合致する。しかし、今日の行動を規定するのは、現在の環境、承認済みバージョン、アクティブなインシデント状態、必要なチェックだけかもしれない。

カバレッジ目的は、テーマ上の広がりを加えるという理由で、過去のインシデントを評価し得る。すると生成モデルは、古い制約と現在の制約を混ぜ合わせる可能性がある。小規模モデルには、時系列、権威性、条件付き適用性を区別するための余力が少ない。

したがって、テーマへの所属は因果的な有用性の弱い代理指標にすぎない。最良の取得エビデンスは、単に質問に関連しているだけではない。回答を実質的に支え、制約し、反証し、または曖昧さを解消する必要がある。

この圧力は、複数ターンのシステムで強まる。Microsoftの研究者らは、テスト対象モデルが複数ターンにわたる会話を処理した際、6つの生成タスク全体で平均39パーセントの性能低下を報告した。会話ベンチマークでは、主要なオープンモデルとクローズドモデルが、同等の単一ターン設定よりも低い性能を示した。

エージェントはさらに別の層を加える。各モジュールは、要約、計画、ツール結果、観測、ステータスメッセージを作成できる。共有メモリシステムはその結果、それぞれ異なるローカル目的のために書かれた、同一事実の複数のバージョンに向き合うことになる。

圧縮はストレージには役立つが、意思決定との関連性を保証するものではない。圧縮された気を散らす情報も、依然として気を散らす情報である。複数の圧縮要約は、どの元の情報源が権威的だったかを不明瞭にすることもある。

検索可能なナレッジベースを構築する人々にとって、ここから得られる実践的な教訓は明確だ。検索品質は、インデックス層やランキング層だけでなく、最終的な回答または行動で評価しなければならない。

カバレッジと精度は文検索を逆方向へ引っ張る

SALTの主な設計上の対立は、トライとベクトルデータベース、あるいはCELFと別の最適化手法の対立ではなく、カバレッジと精度の対立にある。

カバレッジは、選択された集合がトピックの十分に異なる側面を表しているかを問う。精度は、各選択項目がこの特定の判断において、希少なプロンプト空間を占めるに値するかを問う。どちらも有用だが、異なる行動を評価する。

純粋な関連度ランカーは、冗長な文を返しがちである。最高スコアの項目は、わずかな表現の違いで同じ顕著な概念を言い換えている可能性がある。劣モジュラ選択は、すでに選ばれた項目を超える追加価値が小さい候補を割り引くことで、多様性を改善できる。

SALTで報告されているCELFの使用は、この問題を対象としているように見える。基礎となる目的関数が劣モジュラであれば、遅延貪欲選択は高価値な集合を効率的に近似できる。しかし、最適化器が追求できるのは、その目的関数に符号化された価値だけだ。

テーマカバレッジが新しいすべてのサブテーマに価値を与えるなら、システムは広がりを求める。あるサブテーマが単なる背景であり、別のサブテーマに決定的な制約が含まれることを、システムは理解できない。また、計算上の効率だけからこれを推論することもできない。

検索単位も問題を複雑にする。文は採点や並べ替えが容易だが、事実が常に文の境界に従うとは限らない。限定条件を含む文は、近くにある定義、タイムスタンプ、発言者、または例外に依存する場合がある。

一見すると回答に見える文だけを取得すると、必要な出所情報を失う可能性がある。そのテーマ上の近傍全体を取得すれば出所情報は回復できるが、ノイズも増える。システムには、トピッククラスター全体を取り込まずに依存関係を保持するエビデンス単位が必要だ。

1つの選択肢は、主張中心の検索である。システムは各記憶を主張とメタデータとして表現し、メタデータには情報源、時刻、適用範囲、信頼度、必要な限定条件へのリンクを含める。選択は孤立した文ではなく、こうしたエビデンスバンドルを対象に行われる。

もう1つの選択肢は、質問条件付きの限界利得である。候補の価値は、回答を改善するか、曖昧さを解消するか、欠けているステップを補うか、現在の下書きに反証を与えるかに依存する。一般的なテーマの新規性は、主目的ではなく補助的なシグナルとなる。

どちらのアプローチもトレードオフをなくすものではない。主張抽出は取り込み時にエラーを生じさせる可能性がある。質問条件付きスコアリングはレイテンシーを増やし、独自のバイアスを持つ別のモデルに依存する可能性がある。

それでも、両方のアプローチは実際の最適化目標を明らかにする。検索層は、トークン予算とレイテンシー予算の下で期待タスク効用を最大化すべきである。メモリカバレッジを最大化し、余剰情報は生成モデルが捨ててくれると仮定すべきではない。

固定の20パーセントポリシーは、特に厳密な検討に値する。比率はストレージサンプリングには便利だが、プロンプト容量は絶対トークン数に依存する。モデルの信頼性も、クエリの複雑さ、エビデンスの構造、使用する生成モデルによって変化する。

より良い予算配分は、必要な証拠に応じて適応するべきだ。直接的な検索なら、裏付けのある主張が1つで足りるかもしれない。比較には複数の代替案が必要になる場合がある。複数ステップのエージェント計画では、依存関係の連鎖に加え、明示的な矛盾も求められる可能性がある。

これは段階的な検索プロセスを示唆している。最初のパスでは、小規模で高精度な中核を取得すべきだ。2回目のパスは、回答に裏付けがない、不確実性を含む、あるいは追加の推論ステップが必要な場合にのみ拡張する。

拡張の判断には測定可能な基準が必要だ。モデルは裏付けのない主張を特定できるが、自己申告の信頼度だけでは信頼性に欠ける。より確かなシグナルには、引用の欠如、未解決のエンティティ、矛盾するタイムスタンプ、回答可能性チェックの失敗が含まれる。

システムは、安定した記憶とエピソード記憶も分離すべきだ。安定した記憶には、持続的な選好、ポリシー、検証済みの事実が含まれる。エピソード記憶には、イベント、一時的な観測、関連性が時間とともに低下する過去の手順が記録される。

この分離がなければ、テーマ選択器は恒久的なルールと一時的な状態を混同しかねない。基礎となるインシデントが解決した後も、エージェントが古い回避策に従う可能性がある。したがって、テキストがモデルに渡る前に、時間的メタデータが選択へ影響を与えるべきだ。

権威性は新しさと同じくらい重要だ。ユーザーの指示は、その指示をエージェントが要約した内容より優先されるべきである。検証済みのツール結果は、推測的な計画より優先されるべきだ。テーマの類似性だけでは、こうした優先順位を表現できない。

最適な文検索手法は、おそらく複数のシグナルを組み合わせることになる。これには、語彙的一致、意味的類似性、依存関係の網羅性、時間、権威性、矛盾、推定タスク効用が含まれる。目的関数にこうした違いを組み込めば、CELFは依然として最終的な集合選択を担える。

これは、トライ木を無関係にするものではない。ストレージ構造は、検索速度、メモリ負荷、更新の挙動、利用可能な関係性を決定する。つまり、ストレージ効率と回答の信頼性は、異なる評価レイヤーに属するということだ。

小規模モデルは検索の失敗を最初に露呈させる

ここで小規模モデルは、単に生成能力が弱いだけではない。検索レイヤーが証拠とテーマ上のノイズを分離できているかを試すストレステストとして機能する。

大規模モデルは、より強い指示追従能力と優れた文脈識別によって、混雑したプロンプトから回復できる場合がある。この耐性は、検索器の弱点を隠しうる。同じコンテキストでも、小規模モデルは即座に圧倒されかねない。

したがって、開発者によるハルシネーションについての観測は慎重に解釈する必要がある。過剰な検索は裏付けのない回答と相関するかもしれないが、この投稿は因果関係を立証していない。ほかの要因としては、弱いプロンプト、証拠の欠如、矛盾する記憶、デコード設定、モデル固有の制約が挙げられる。

ハルシネーションという言葉も、複数の失敗を一括りにしてしまう可能性がある。モデルは事実を捏造するかもしれないし、2つの記憶を混同する、古い指示に従う、あるいは検索された選択肢の中から誤ったものを選ぶこともある。それぞれの失敗には異なる測定方法と、場合によっては異なる修正が必要になる。

SALTは、選択器を変更する前にエラー分類を用意する必要がある。失敗したすべての回答について、必要な証拠が欠けていたのか、存在したが無視されたのか、矛盾していたのか、不完全だったのか、あるいは気を散らす情報に埋もれたのかを特定すべきだ。

評価では少なくとも4つの検索条件を比較すべきである。1つは外部メモリをまったく提供しない条件。別の1つは、人間が選んだオラクル証拠セットだけを提供する条件。3つ目はSALTの現行出力を用い、4つ目は積極的に削減した出力を使う。

この比較により、検索と生成を切り分けられる。小規模モデルがオラクルセットでも失敗するなら、CELFの重みを変えても中核的な問題は解決しない。オラクル証拠では成功する一方でSALTの出力では失敗するなら、精度が最優先の目標となる。

ベンチマークは現実的なタスク分類を維持すべきだ。直接的な事実質問は正確な想起を試す。マルチホップ質問は依存関係の完全性を試す。エージェントタスクは、取得された記憶が正しいツール選択、パラメータ、停止条件につながるかを試す。

各カテゴリにはネガティブケースが必要だ。コーパスには、同一テーマでありながらもっともらしいが無関係な文、真の事実の古いバージョン、明示的な矛盾、重複した言い換えを含めるべきである。簡単なランダムの妨害情報では、システム品質を過大評価してしまう。

評価では証拠の位置も変化させなければならない。Gemini 2.5 Flashに関するcontext-limit resultsは、新しいモデルが長大なコンテキスト内での単純なニードル検索を、従来のシステムよりはるかにうまく処理できることを示している。この知見は、コンテキストが普遍的に失敗するという広範な主張に対する重要な反証となる。

しかし、単純な事実検索は、競合する記憶をまたぐ推論とは異なる。モデルは意図的に埋め込まれた1つの事実を見つけられても、複数の関連する主張、例外、時間的変化にはなお苦戦する可能性がある。SALTのエージェント利用ケースは、後者のカテゴリにより近い。

したがって、テストではモデル規模とコンテキスト構成を掛け合わせるべきだ。同じ取得セットを、小規模なローカルモデル、より強力なモデル、オラクル形式の評価器に渡す。差異を見れば、改善がよりクリーンな記憶によるものか、生成器の能力向上によるものかが分かる。

精度は複数のレベルで報告すべきである。文精度は、取得した文のうち有用なものの割合を数える。主張精度は、裏付けられた命題を数える。行動精度は、エージェントが正しい操作とパラメータを選ぶかを測る。

再現率も可視化したままにしなければならない。明白な1文を除くすべてを削れば、精度は上がる一方でマルチホップの完全性が失われる可能性がある。安全な選択器は、単に最小の集合ではなく、最小限で十分な証拠集合を特定すべきだ。

「十分」とは、その集合が正しい結果を裏付け、必要な限定条件を保持することを意味する。また、記憶内に相反する主張がある場合は、決定的な矛盾も含めるべきだ。そうでなければ、コンパクトなプロンプトが自信満々に誤ったものになり得る。

アブレーションテストにより、どのSALTコンポーネントが有効かを明らかにできる。研究者は、テーマ網羅性を無効化する、割合ベースの予算を変更する、絶対トークン数に上限を設ける、重複を除去する、新しさを追加する、権威性の重み付けを追加するといった操作を、それぞれ個別に行うべきだ。

こうした実験では、保存された記憶とクエリを同一にする必要がある。実行ごとにコーパスを変更すると、比較が難しくなる。生成でサンプリングを用いる場合は、試行を繰り返すことも重要だ。

レイテンシとメモリ使用量は、なくすのではなく副次的な指標として維持すべきだ。精度を改善しても許容できない遅延を加える再ランカーは、対話型エージェントを損なう可能性がある。目標は、精度、トークン数、レイテンシ、DRAMにわたる測定可能な運用フロンティアである。

開発者は、取得した各文が何に寄与したかも記録すべきだ。簡潔な理由コードにより、語彙的一致、新たな主張、矛盾、時間的依存関係、ソースの権威性を特定できる。こうしたログがあれば、生成器に自己説明を求めずに過剰な検索を診断できる。

重要なリスクの1つは、なお未検証のままである。SALTの現在のチャットボット精度、メモリ圧縮、エージェント性能を確立する公開ベンチマークは存在しない。このアーキテクチャは、検証済みの進歩ではなく、初期プロジェクト報告として論じるべきだ。

SALTがエージェントへ拡張できるかを示す3つのシグナル

SALTの次のマイルストーンは、より大きなメモリストアやより寛大なコンテキスト予算ではなく、再現可能な精度の結果であるべきだ。

第1のシグナルは、オラクルギャップ・ベンチマークである。開発者は、直接回答、マルチホップ、エージェント行動タスクにわたり、現在の検索を人間が選択した最小限の証拠セットと比較すべきだ。結果はモデル規模別に分解する必要がある。

SALTがより少ないトークンでオラクル性能に近づくなら、その証拠はテーマ選択戦略を支持することになる。小規模モデルでギャップが拡大するなら、現行の目的関数は生成器が利用できない広がりを選んでいることになる。

第2のシグナルは、適応的な予算配分だ。固定の20パーセント方針は、絶対トークン上限や段階的検索と競わせるべきである。この比較では、回答精度、行動の成功、取得された主張、レイテンシ、裏付けのない断言を測定する必要がある。

適応的な方針が勝利するのは、完全な証拠の連鎖を保持できる場合に限られる。例外や依存関係を取り除くなら、トークン数の削減だけではシステムを弱めることになる。最も強い結果は、タスクレベルの再現率を落とさずに精度を改善することだ。

第3のシグナルは、エージェント試験中のモジュール対応プロベナンスである。各メモリは、元となったモジュール、タイムスタンプ、権威性、ソース資料を特定すべきだ。テストには、異なるエージェント由来の相反する記憶や古い記憶を含める必要がある。

プロベナンスを考慮した選択が誤った行動を減らすなら、マルチエージェント記憶にはテーマ支配以上のものが必要になる。権威性、新鮮さ、矛盾に関する明示的なルールが必要だ。プロベナンスの効果が小さいなら、主な問題はランキングや生成の別の箇所にある可能性が高い。

これらのシグナルは、オープンな評価パッケージの中で提示すべきだ。パッケージには、固定クエリ、ラベル付けされた証拠、検索ログ、生成出力、モデル設定、採点ルールが必要である。こうした成果物がなければ、外部の貢献者は提案された変更がなぜ機能するのかを切り分けられない。

完全なベンチマークが存在する前でも、コミュニティの提案は有用になり得る。プロジェクトは、最大限界関連性、クロスエンコーダ再ランキング、主張クラスタリング、クエリ重視の圧縮を試せる。しかし、逸話だけを根拠に、どの手法も現行の選択器に取って代わるべきではない。

最も有力な短期設計は、おそらく保守的なものだ。コンパクトな証拠の中核を取得し、それに付随する限定条件を保持し、特定の情報ギャップを検出した場合にのみ拡張する。1つの広いコンテキストを一斉配信するのではなく、各モジュールのタスクに応じて選択された証拠を振り分ける。

エージェントシステムには、メモリ衛生も必要だ。重複を統合し、一時的な状態を期限切れにし、元のソースを保持し、観測と結論を区別すべきである。そうしなければ、エージェントが以前の出力の派生物を繰り返し保存するにつれ、検索品質は低下する。

このパターンは、損失のあるコピーに似ている。ツールが事実を生成し、あるエージェントがそれを要約し、別のエージェントがその要約をさらに要約し、メモリシステムがすべてのバージョンを保存する。テーマ網羅性は、共通の起源を持つにもかかわらず、こうした項目を一貫した証拠として評価してしまう可能性がある。

プロベナンスを考慮した重複排除は、繰り返しのコピーによる見かけ上の合意を防げる。選択器は、派生した記憶を元の証拠の下にグループ化すべきだ。そうすれば、1つの事実を複数の言い換えでプロンプトトークンを費やすことを避けられる。

personal knowledge systemを構築するチームも、関連する課題に直面している。すべてを記録することが有用なのは、想起が関連性、ソースの境界、時間を保持する場合に限られる。エージェント記憶は、こうした区別を誤るコストを増幅させる。

horizon machinelearningの議論において、これが決定的なポイントである。SALTは、トライ木が膨大な会話メモリを保存できることを証明する必要はない。メモリとモジュール数が増加しても、選択器が最小限で十分な証拠集合を回収できることを示す必要がある。

したがって、次に有用な貢献は測定可能なものだ。失敗セットを公開し、必要な証拠にラベルを付け、同一のモデル条件下で検索方針を比較する。必要な事実を隠さずに、小規模モデルの精度を保てる方針はどれか。

 
 

無料で始めましょう

ローカルファーストのパーソナル知識管理付きAIアシスタント

より良いAI体験のために、

remio は現在、 Windows 10+ (x64)M-Chip Mac のみをサポートしています。

脳内に検索バーを追加

ただremioに尋ねるだけ

すべてを思い出す

何も整理しない

bottom of page