なぜAIコーディングアシスタントは同じミスを繰り返すのか：結果を受け取るのは誰なのか？

固定した誤りは、それを運ぶ記憶が検索され続けているかぎり、何度でも戻ってくる。訂正を書き留めても、それだけでは止まらない。古いエントリはストレージに残り、取得の対象であり続け、次のセッションが始まれば、またモデルの前に現れる。あなたの訂正のすぐ隣に、両者を隔てるものもなく並ぶ。誤りを保存することと、誤りから学ぶことは別物だ。保存とは、その誤りがもう一度読まれうるということにすぎない。学習とは、結果が悪かったという理由で、システムのその後の振る舞いが変わることだ。この不満の底には、このカテゴリのあらゆる製品に——私たちのものも含めて——投げかけられる、機械的な問いがひとつある。結果が悪かったとき、何かが変わったか？ 新しいことを書き込んだときではない。何かが失敗したときだ。

開示する。しかもこのページでは、それは議論の後ではなく前に置かれるべきだ。私たちは Mnemoverse を作っている。AI agent 向けのメモリレイヤーだ。つまりこれは、あるベンダーが自社を5つの競合と比較しているということであり、この特定の問いについては私たちが勝っている。まさにそのために、フッターではなく今ここで伝えておく。私たちは結果のための入力のひとつを公開していて、ドキュメントもあり、値はマイナス1からプラス1の浮動小数点数だ。その入力についての私たち自身の公開記事は、私たちが計測したトラフィックの中でそれがほとんど呼ばれたことがないと報告しており、このページはそこで終わっている。以下の引用はすべて、開けるページの中の連続した部分文字列で、クエリはすべて印刷してあるので自分で実行できる。そして私たちの成績が最も悪いセクションは最後に置いた。

このページは、2026年9月8日に走らせたスキャンから来ている。同じ6つのシステムに同じ問いを投げた。そのスキャンから、2か所はより深く掘り下げ、1か所はさらに先へ進んだ。3か所とも、それが着地した位置で印を付けてある。あのスキャンは各マーケティングホストでベンダーの changelog を探し、各ドキュメントツリーから1ページしか読まなかった。どちらも狭すぎた。

このページには性能の数字はひとつもない。私たちのものでも、他人のものでも。数字はレシピの産物であり、このページはレシピを示していない。レシピのない数字は、あなたが検証できるものではない。

これは動画《どうすれば私の AI コーディングアシスタントがセッションをまたいで同じ誤りを繰り返すのを防げるか？》の文字起こしだ。動画は7つの章に分かれ、同じ6つのシステムに同じ問いを投げている。以下の章は、動画が深く踏み込めなかった箇所を掘り下げている。ここに現れる引用とクエリはすべて、動画で読み上げられたものと完全に一致する。

14:17

TL;DR

間違いを保存することと、そこから学ぶことは別物だ。 agent memory を名乗るものは、最初の仕事だけはどれもそこそこやる。二つ目には、返ってきたものが間違っていたと知らせる事後報告が要る。

残り五つのうち四つは、明確な否定判定を返せる入力口を公開している。 Cognee、Mem0、Letta、Supermemory を、いずれも 2026 年 9 月 10 日に公式ドキュメントサイトで確認した。見た範囲では、Zep だけが公開していない。

その入力を何に紐づけているかが、分かれ目になる。 一度の recall への回答、一件の記憶、一つの実行ステップ、あるいはエンジンが事実について下した推測。四つはそれぞれ別の対象で、この記事が問うているのはそのうち二つだけだ。

その入力が何を変えるのかまで書いているものは、さらに少ない。 Cognee はフィードバックが今後の検索に影響すると述べ、適用される呼び出しまで名指ししている。Supermemory は未審査の推測が検索で降格されると述べている。Mem0 のページに書かれているのは endpoint が何を受け取るかであって、順序がどう変わるかではない。Letta のページは検索順序に一切触れていない。

否定の方向を表す語の完全な綴りは、五社のコード構成のどこを探してもゼロ件だった。 2026 年 9 月 10 日に再実行し、どの社でもヒットを返す対照クエリを添えた。クエリは下に載せてある。

ハイフン付きの綴りはゼロではない。 このページは、あなたがそれを見つける前に先に書いておく。Supermemory は審査に関するドキュメントで down-weight を公開しており、Cognee はあるガイドで公開している。ただし後者は、自分たちの検索が何をしないかについての一文だ。

我々の場合：入力口は文書化され、エンジンは非公開、シグナルは設計上任意だ。 endpoint と値域と説明は読める。動いているところは見られない。

9 月 8 日のスキャンと食い違う点は、すべて本文中で明示した。 そのスキャンの限定的な結論二つは、それが読んだ画面では成り立つが、以下のページでは成り立たない。そこから導かれた結論一つは、証拠の範囲を超えている。三つとも、該当する箇所で名指ししてある。

開示、しかも論証の前に

本ページで扱う六つのシステムのうち一つは、我々が作っている。Mnemoverse は agent 向けのマネージド記憶層であり、この記事が問うている点について我々は強い立場を持っている。立場が弱いより悪い。信じない理由が増えるからだ。

だからまず、立場をその限界ごと先に出す。我々の API ドキュメントは、この記事全体で扱うフィールドをパラメータ表に記載しており、肝心なのは値域のほうだ。「Outcome signal: -1.0 (failure) to +1.0 (success)」。同じページに呼び出しの用途も書いてある。「Report outcome (success/failure) for memories.」機械可読インデックスも、それを読む agent に同じことを伝え、さらに何が変わるかを補っている。recall した記憶が役に立った（+1）か間違っていた（-1）かを報告すると、そこに三語が続く。「This tunes future recall.」

そしてここが我々の失点だ。 我々のエンジンは非公開だ。mnemoverse-core は公開リポジトリに含まれていない。endpoint と値域と説明は読めるが、これが効くかどうかを実際に決める部分は読めない。endpoint にはアカウントとキーが要る。ここでいう「公開」はドキュメントが公開されているという意味で、誰でも使えるという意味ではない。このページの締めくくりは、我々自身についての測定結果だ。シグナルは存在するが、ほとんど送られていない。

もう一つ、我々の側の何かに触れる前に必ず目に入るものがある。公開している memory-server リポジトリのトップの説明文には、我々自身の changelog がすでに取り下げた挙動が二つ、いまも宣伝文句として残っている。二日前にこのサイトで書いた。Cursor Memory Bank: what actually loads を読んでいる今この瞬間も、まだそこにある。

この記事のクエリはどれも、他人にも我々にも向けられる。まず我々から始める。

間違いを保存することは、そこから学ぶことではない

一度直したはずだ。理由も説明した。次のセッションで、また戻ってきた。

ここでいう「記憶」は実は二つの別のもので、切り分けてしまえば作業の大半は終わる。一つは保存。間違いや修正がどこかに書き込まれ、また読める。もう一つは学習。前回の結果が悪かったために、システムの次の振る舞いが変わる。

agent memory として売られているものはほぼすべて最初のほうだけをやっていて、それはそれで悪くない。ノート、ファイル、グラフ、ベクトルインデックス、マネージドストレージ。どれも保存であり、保存は役に立つ。だが対称的でもある。間違った助言を覚える忠実さは、修正を覚える忠実さとまったく同じで、両方を同じ確信度で返してくる。

二つを分ける検査は三つあり、どれも自分で実行できる。

結果を受け取る入力口はあるか。 新しいノートを書く場所ではなく、いま渡されたものが間違っていたと知らせる報告だ。
あるなら、それは何を変えるのか。 記憶のテキストか、その重みか、それとも返ってくる順序か。
その変化は再起動をまたいで残るか。そして、それは目に見えるか。

このページの残りでは、これら3つのチェックを6つのシステム——Cognee、Letta、Mem0、Supermemory、Zep、Mnemoverse——に当てはめていく。

エラーを二度と戻らせないために、何を変える必要があるか

まず仕組み、次に製品について述べる。仕組みが、何を見るべきかを決めるからだ。

コーディングアシスタントが記憶を参照する方法は、あなたがノートをめくるのとは違う。何かが少数の項目を検索してモデルの前に並べ、モデルはそれを受けて何かを書く。誤った項目がその少数の中に居続ければ、モデルは同じ悪い考えを出し続ける。モデルが頑固なのではなく、与えられているものが間違っているのだ。

ここから、テコをどこに置くべきかが見えてくる。誤った記憶を削除するのは1つの答えであり、非常に乱暴だ。 検索された項目のうちどれが悪いのかを知らなければならず、それはつまりそれらを読むということであり、まさに避けたい作業だ。しかも、かつて誤っていた記憶は、別の場面ではしばしば正しい。デプロイパスに関するあのノートは、あるサービスには正しく、次のサービスには誤解を招く。削除すれば、どちらも失う。

並び替えにはこの2つの問題がない。 何も破壊する必要がなく、同じ項目をある種の問いでは下位に、別の種では上位に置ける。ただし、書き込みパスには提供できないものが必要だ。返されたものが誤りだったという事後の報告、つまり結果である。

だから本稿は入力の話をしており、ストレージ形式の話はしていない。ここにあるどのシステムも、修正を1つ保存することはできる。問題は、悪い結果の下流にある何かが、次に何を返すかを決めるものに手が届くかどうかだ。

うまくいったやり方を残すことと、うまくいかないやり方を正すことは別物だ

agentがエラーから学ぶ方法を検索すると、返ってくる結果の多くは問題のもう半分を扱っている。つまり、うまくいったワークフローをどう残して再生するかだ。それは確かに現実的な製品の方向性であり、多くの場所で明確に説明されている。だが、ここで問うていることではない。この2つは似て見えて、振る舞いはまったく違う。成功は起きたその場で捉えられるが、失敗はたいてい捉えられないからだ。

ベンダーのページにも同じ分かれ目が現れている。Lettaのクイックスタートドキュメントは、agentが間違えたときどうすべきかを説明しており、そこで示される操作は永続化の書き込みだ。「間違えたときは、二度と同じ間違いを繰り返してはならない」として、/rememberコマンドでその修正を固定する。これはストレージであり、意図的に、そしてうまく作られている。前節の第1の種類であって、第2の種類ではない。

Supermemoryのreviewエンドポイントは第2の種類に見えるが、実際はまた別の、第3のものだ。これらは、あなたが明示的に述べた記憶ではなく、エンジンが推論した記憶に対して承認・拒否・取り消しの判断を下させる。ベンダー自身のページは効果を正確に書いている。記憶が審査される前、推論状態にある間は「検索で降格され」、承認されれば明示的に述べられた事実と同等に順位付けされ、拒否されれば「検索から完全に削除される」。これは、導き出された事実が成り立つかどうかについての裁定であって、ある検索結果がどうだったかについての報告ではない。どちらも役に立つが、互換ではない。両方をfeedbackという1つの機能比較表にまとめるのは、2つの異なる仕組みを比べていることになる。

そもそも結果を受け取るものはあるのか

この節は、本ページがその元になったスキャンを超える部分なので、まず違いをはっきりさせておく。 そのスキャンは2026年9月8日に実行され、各ベンダーについて6つの面——ドキュメントツリー、changelog、release notes、GitHub組織とキーワード検索、機械可読インデックス、フォーラム——を対象にした。Cognee、Supermemory、Mnemoverseはchangelogから答えを得られたが、我々自身のものは独立したアドレスではなくコードリポジトリで見つかった。Letta、Mem0、Zepについては、このスキャンはchangelogをまったく見つけられなかった。スキャン自体の結論には厳密な限界があり、そのまま繰り返す価値がある。まさにこの限界があるからこそ、以下の違いは訂正ではなく拡張になるのだ。資格情報が届いた面において、6社のうち3社は、結果が悪かったために検索を変える入力について何も記述していなかった。名指しされた3社はMem0、Cognee、Zepである。この記述はそれらの面については成り立つが、その下のページについては成り立たない。それらの資格情報におけるドキュメント面は、各ドキュメントツリーから1ページだけ取得したものであり、これらのフィードバック入力を説明するページはずっと下の階層にある。2026年9月10日にドキュメントホストで見直したところ、3社のうち2社がそのような入力を公開していた。

以下は、この5社がそれぞれ何を公開しているかだ。各行は横に示したページから取り、2026年9月10日に読み直した。

システム	公開されている、否定的判定を載せられる入力	何に付くか	効果についてのベンダーの公開説明
Cognee	`cognee.session.add_feedback`、フィードバックテキストと1〜5点の評価を添付できる	1回の検索で得られた答え。セッション内の識別子を通じて	「フィードバックを後続の検索に反映させるには、関連するsession_idsを付けてimprove()を実行してください。」
Mem0	`POST /v1/feedback/`、値はPOSITIVE、NEGATIVE、VERY_NEGATIVE	1件の記憶結果。`memory_id`を通じて	ページはこのエンドポイントの用途を「記憶結果に対して肯定的または否定的なフィードバックを送信する」と述べるだけで、順位付けに何が起きるかには一切触れていない
Letta	`PATCH /v1/steps/{step_id}/feedback`、「そのフィードバックが肯定的か否定的か」	1つの実行ステップ	ページはこの操作を「指定されたステップのフィードバックを変更する。」と説明し、検索順序とは結びつけていない
Supermemory	審査エンドポイント、approve、decline、undo	エンジンが推論した記憶。あなたが明示的に書いたものではない	審査前の推論記憶は「検索で降格され」、拒否されたものは「検索から完全に削除される」
Zep	読んだインターフェースでは見つからなかった
Mnemoverse	`memory_feedback(atom_ids, outcome)`、「結果シグナル：-1.0（失敗）から+1.0（成功）」	1回の検索が返した記憶	「これは後続の検索を調整する」と述べ、同じインデックスに「不要な記憶は削除されるのではなく、後ろに並べられる」と書いている

Cognee は最も明確な一例であり、率直に書く価値がある。 フィードバックのガイドには「Recall した回答へのフィードバックは Sessions で処理される」とあり、続けてこのやり取りをどう記録するか、採点したい回答の識別子をどう見つけるか、それに対して add_feedback をどう呼び出すかが順を追って説明されている。そして最後に、ここで最も重要な一文が来る。「フィードバックを後続の検索に反映させるには、関連する session_ids を付けて improve() を実行してください」。これは検索された回答への入力であり、そこから次の検索の挙動へと戻っていく公開された経路がある。まさに、あの調査が触れていなかった仕組みだ。

Mem0 も入力を一つ公開している。 そのエンドポイントは docs.mem0.ai/api-reference/memory/feedback に記載され、記憶の識別子と三つの値のうち一つを受け取る。そして正直な境界線は、このページが語っていない部分にある。書かれているのはこのエンドポイントが何を受け取るかだけで、その後に順位付けがどうなるかではない。Mem0 は他にも changelog で検索時のランキングバイアスを公開している。一読の価値があるのは、それが結果の順序を変えるのに判定を一切受け取らないからだ。その項目はプロジェクト単位で効くバイアスを説明し、最近触れられた記憶を押し上げ、「検索で返された各記憶はアクセス履歴を更新する」と指摘し、「減衰は候補を並べ替えることはあっても、削除することはない」と書き、デフォルト値はベンダー自身の言葉でこう示されている。「デフォルトはオフ。プロジェクトエンドポイントの decay フィールドでプロジェクト単位に有効化する」。頻度と近接性はその順序を変える。回答が正しいかどうかは変えない。

Letta の入力は確かに存在する。ただし別のものに紐づいている。 step は実行オブジェクトで、それに正や負を付けられる。可観測性と評価には役立つ。だが、ある検索された記憶が誤っていると報告しているわけではない。あのページにも quickstart にも、この二つが以降の読み出し順を変えるなどとはどこにも書かれていない。

Zep は本記事で唯一「存在しない」と断言した箇所であり、その境界は同じ段落に書かれている。 読んだ範囲のインターフェースで、Zep が公開している内容のどこにも、検索結果に判定を下す入力は記述されていない。getzep.com/llms.txt の機械可読インデックスは 2026 年 9 月 10 日時点で 3,963 バイト、feedback、outcome、valence、rerank、reinforce、downweight の出現回数はいずれもゼロであり、このファイルは明らかに空ではない。help.getzep.com/sitemap.xml に列挙された 324 ページを同じ日に一つずつ辿ったが、feedback という語の出現はすべてサンプル内容で、入力ではなかった。getzep の組織に対する用語検索では、対照語はファイルにヒットするのに、本記事が扱う語は一つも出なかった。カバーできていない部分はこうだ。help.getzep.com/changelog の changelog はページ分割されており、直接取得するとページ先頭しか描画されない。本記事はこれに依拠した結論を一つも出していない。製品の非公開部分は外部からはまったく読めない。

本記事全体に当てはまる境界が一つある。 この六社のうち四社は、我々を含め、公開された読めるエンジンを持っていない。公開されている内容をざっと見ることは、実際に動いているものをざっと見ることではない。本記事があるものは存在しないと述べるとき、それは読み取り当日にここに挙げたページとリポジトリを指しており、ある製品の挙動を指してはいない。うち二社は外部から読めないチャットコミュニティも運営している。今回の調査はそこをカバーしておらず、答えがそこにあるなら、本記事にもない。

調査が見つけられなかった changelog と、その理由。 調査は Mem0、Letta、Zep の changelog を「見つからず」と記録した。これは調査自体についての真実の陳述であり、ベンダーについてのものではない。インターフェースの欠落を示しているのであって、ベンダーの沈黙を示しているのではない。この三社の changelog は存在し、いずれもマーケティングドメインではなくドキュメントドメインにある。調査が見ていたのは前者だ。2026 年 9 月 10 日、docs.letta.com/reference/changelog は 200 を返し、412,108 バイト、約八万四千文字のテキストがあった。同じドメインの架空のパスは 404 を返し、テキスト量はその約二十分の一だった。docs.mem0.ai/changelog は 200 を返して /changelog/highlights に解決し、help.getzep.com/changelog は 200 を返して /v3/changelog に解決した。最初のものは到底推測できない。docs.letta.com/changelog がクライアント SDK のページに解決するからだ。調査の幅は、その最も狭いインターフェースで決まる。本記事が調査より深く踏み込んだ二箇所は、どちらも同じ種類の誤りから生じている。

文脈から学ぶことは結果から学ぶことではない

五社のうち二社は、学習の仕組みがどうあるべきかについての立場を明記しており、どちらの一節も要約せず直接引用する価値がある。両社とも学習を文脈の中に置いている。

Supermemory は、自社の機械可読インデックスについて。 文の主語は彼らのモデルであり、一般化された製品ではない。「Our model, learner-1, extracts and dreams on the context of every user, task, and tenant」。同じファイルに「Memory that keeps learning」という小見出しがある。これが学習であり、文脈からの学習だ。起きた出来事がより多く投入され、モデルはより良いブリーフィングを受け取る。この文は、前回の回答が良かったかどうかについて何も判断していない。先に触れた review インターフェースが判断するのは推測であって、結果ではない。

Letta は、自社が発表した継続学習の研究について。 論点は学習がトークン空間で起きるべきだというもので、文には「すでに」ではなく「べき」が入っている。「updates to learned context, not weights」。そしてこれが、agent が経験から学ぶ際に取るべき第一の仕組みだと述べている。根底にある枠組みはこうだ。デプロイ済みのモデルは、人が思うようには学習できない。なぜなら「their weights are frozen at deployment」だから。

あのページで人について述べた一節は人間を語ったものであり、ここで最も誤って引用されやすい箇所でもある。 Letta は人間を引き合いに出す。「Humans continually learn and improve over time」、新しい技能を習得し、自らの信念を更新し、そして「modify their behavior to correct for past mistakes」。これは模倣すべき対象を描写しているのであって、Letta の agent が何をするかという話ではない。主語を外して引用すれば、彼らの代わりに語ったことになる。

同じページは例外をひとつ挙げている。だからここでも挙げておく。 重みが凍結されているという件のすぐ後に、Letta はこう書く。「The one notable exception is Cursor's tab-completion model which uses online RL to continuously improve based on user feedback, but this form of continual learning operates at the population level, improving the model for everyone rather than enabling individual agents to learn from their own experience.」さらにこう付け足す。「it is scoped to a narrow domain: short code completions, not general reasoning and actions」。つまり、すでに稼働し広く使われている仕組みが実在する。ユーザーのフィードバックで学習し、それがコーディングツールの中にあり、制約はどちらもベンダー自身が認めている。改善されるのは全員のモデルであって、あなたのプロジェクトのあのバグが直るわけではない。対象は補完であって、推論と行動ではない。この分野では誰も結果から学習していない——どこかでそう読んだことがあるなら、私たち自身の以前のバージョンの主張も含めて——その一文が反例であり、しかもこの記事が別の用件で引用しているページに印刷されている。

この語と、それが現れる二つの場所

この仕組みには独自の語彙がある。だからスキャンは各ベンダー自身の組織の中でこれらの語を検索する。Feedback。Outcome。Valence。Rerank。Reinforce。あとひとつ：downweight——検索で拾い上げたものの、結果的に誤りだと判明した項目に対して行うべきこと、それを指す語がこれだ。

クエリ自体は複雑ではないし、私たち自身のものはひとつも入っていない。語を引用符で囲み、組織名を続けるだけだ。

"downweight" org:topoteretes
"downweight" org:letta-ai
"downweight" org:mem0ai
"downweight" org:supermemoryai
"downweight" org:getzep

これは GitHub コード検索のクエリで、コマンドラインでは gh api -X GET search/code -f q='"downweight" org:topoteretes' --jq .total_count の形になる。2026 年 9 月 10 日に再実行したところ、五つすべてがゼロを返した。

このゼロは三つのことに縛られており、そのどれもが過度に頼るべきでない理由になっている。

ひとつ目は単位。GitHub コード検索が数えるのはファイルであって出現回数ではない。そこでのゼロはインデックスの中のゼロであり、現実世界のゼロではない。github.com のウェブ UI は別のインデックスを使っており、同じクエリでも違う数字が出ることがある。

ふたつ目は対照。対照がなければ、陰性の結果は何も証明しない。同じツール、同じ日、同じ五つの組織で "rerank" を検索して返ったファイル数は、十三、三、百四十四、二十八、百六十三。インデックスはどの組織についても答えている。隣でもう一つ別のツールを走らせた。2026 年 9 月 10 日に各社のフラッグシップリポジトリのデフォルトブランチを直接ダウンロードし、ローカルで検索したところ、ハイフン綴りはどれにも現れなかった。この二つ目のツールには名指ししておく価値のある穴がひとつある。静かにゼロを返す類の穴だ。letta-ai/letta のデフォルトブランチは今や十六ファイルしかなく、README とポリシー文書がひと揃いで、コードはもう載っていない。検索してもほぼ何も証明できない。そこで letta-ai/letta-code を検索した。二千百九十二ファイルあり、この語を検索してもやはりゼロだった。

三つ目は綴り。そしてこれがこのスキャン全体で唯一、結論が証拠を超えた箇所だ。負の方向について誰も書き残していない、という結論である。書いている人はいる。五社のうち二社が書いており、ハイフン綴りを使っている。 Supermemory は前に引用したレビュー文書に書いており、同じクエリにハイフンを足すと彼らの組織でひとつのファイルが返る。Cognee は事実の有効性についてのガイドに書いており、その文は彼らの検索が何をしないかを述べている。「検索とグラフ補完はどちらもクローズ済みノードをフィルタも降格もしないので、置き換えられた事実が結果に現れることがある」。このページは彼らの GitHub 組織の中にはないので、コード検索はゼロを返す。それでもページにはこう書かれている。何かが存在しないと断言するのにツール一つでは足りないことを示す、ここで最も明快な例だ。

では、このゼロは何を語っているのか。 これらの製品の内部で何も起きていないという意味ではない。何かをしているのに名前を一度も与えていないコードは大量にあるし、二社は普通のクエリでは一致しない綴りを使っている。語彙の分布が非対称だということだ。Rerank はどこにでもある。一方、下降の方向——悪い結果に基づく降格——が書き残されているのは五つの組織で二度だけ、しかもそのうち一度は、この状況は起きないと説明するための一文だ。

念のため、同じ日に同じ方法で自分たちの公開リポジトリ十五個すべてをダウンロードして検索した。この語の四つの綴りを合わせて、返った結果はゼロ。私たちも公開していない。

私たち自身の製品と、私たちが作った経路

次は私たちの番だ。この問題については、私たちは他の誰よりも上手くやっている。だからこの節は短くならず、むしろ長くなり、開示は冒頭ではなくここに置く。

私たちは API リファレンスと機械可読インデックスの中で、結果に対する入力——負の値を取るもの——を公開している。リファレンスのパラメータ表には範囲が明記されている。「結果シグナル：-1.0（失敗）から +1.0（成功）まで」。負の1は、まさにこの記事全体が扱っている状況だ。返ってきたものは間違っており、報告はそれを正直に記録する。

これが何に紐づくかが、上記4つの入力のうち3つとの違いだ。 この呼び出しは atom 識別子、つまり recall が返した記憶を受け取る。だから判定は、実際にモデルの前に差し出された項目に下る。実行ステップに下るのではない。チャットの返信に下るのでもない。エンジンが事実について立てた推測に下るのでもない。私たちが公開しているシグナルの定義は、何を報告するかをこう説明している。「呼び出された記憶が役に立ったのか、誤解を招いたのか、それとも使い終わったら無視すべきだったのか」。

そしてこれが変えるのは次回の読み出し順であって、記憶のテキストではない。 記憶はその場に残る。私たちのインデックスは効果を自分の言葉で説明している。「This tunes future recall」。同じファイルの別の箇所にはこうある。「unhelpful memories are out-ranked rather than erased」「outcome feedback re-ranks what comes back next」。

このすべての境界は私たち自身が引いたもので、以下がその境界だ。 それを実証できるエンジンはクローズドソースで、他の5つのうち3つも同じだ。このエンドポイントにはアカウントとキーが要る。範囲と説明は読めるが、ランキングがどう変わるかは見えない。読者が検証できる範囲で言えば、私たちはここにいる誰よりも有利ではない。そしてこのシグナルについての私たち自身の記事も、自分たちの測定について一文でこう述べている。「それは私たちのやり方であって、独立した証拠ではない」。

agent が自分を間違っていたと認める仕組みは存在しない

もう一点言っておく。そしてこれこそが、このページが存在する理由であり、自分たちの機能についてのページを書くのではない理由だ。

入力は私たちが作った。私たちが書き下した。そしてそれについて私たちが発表した記事、The Feedback Dilemma は、明示的な結果フィードバックが「本番トラフィックにはほぼ完全に存在しない、少なくとも私たちが測定したトラフィックには」と述べている。この後半は私たち自身の発見に対する限定なので、文全体を引用する。言っているのは私たちに見えるトラフィックのことであって、すべての本番トラフィックではない。

理由は同じ記事の中にあり、それはこのエンドポイントの欠陥ではない。結果を報告するには、agent が答えを書き終えた後に自ら進んでやる必要があり、その時点で見ているものは何もない。私たちの指針は、採用された recall 1件につきフィードバック呼び出し1回。記事はその利点と代償も説明している。「これによりシグナルはアカウント単位で任意になる」。行動は監査可能になり、同じ記事の言葉を借りれば「偽のラベルを無理に作ることを避ける」。任意であることは正直な言い方であり、同時に限界そのものだ。入力を持っているからといって、同じ間違いが二度と起きないわけではない。 誰も呼び出さない経路と存在しない経路は、同じ繰り返しエラーを生む。これがこの種の仕組みの現状について最も公正な要約であり、私たち自身の仕組みも例外ではない。

これは本サイトに掲載されたルールファイルに関する発見とちょうど裏表の関係にある。ルールを書き下ろし、agent がそれを読み返すのを見て、それから平気で同じ違反をするのを見るなら、それを止めるものは最初から何もなかった。そしてここでは、修正済みのエラーが再発するのを防ぐ仕組みが、agent が自分から間違いを認めることに依存しており、それをさせるものは何もない。

1分でできるテスト、手持ちの道具だけで

どんな比較の結論であれ——この記事のものも含めて——信じる前に、これをやってほしい。何もインストールする必要はなく、この記事に出てくるどのツールにも当てはまる。

自分のツールの中から、間違っていると分かっている記憶を1つ探す。その記憶が答えるような質問を投げ、間違った項目が返ってくるのを見る。それからツールに間違いだと伝える。ツールが許すどんな方法でもいい。インターフェース、レビュー操作、スラッシュコマンド、会話の中の一言。次に新しいセッションを開き、同じ質問をもう一度投げる。コンテキストウィンドウに、あなたの代わりにそれをやってくれるものが残らないようにするためだ。同じ項目がまた最初に返ってくるなら、その報告は今回のトップ結果を変えなかったということだ。そこで分かるのはそれだけだ。その下の項目は並び替わっているかもしれないし、順位を跨ぐには小さすぎる重みの変化も、ここでは痕跡を残さない。ツールが全リストを表示するなら、全リストを比べればいい。トップ結果が変わったなら、得られたのは変化であって、原因ではない。もう一度読んでも何も変わらない。ストレージはすでにその報告を受け取っているので、2回目の読み出しで分かるのは新しい順序が安定しているかどうかだけだ。報告だけを切り離せるのは、それが一度も触っていない対照だ。同じ種類の間違った記憶をもう1つ選び、同じように新しいセッションで質問し、報告は一切送らない。報告した側が動き、触っていない側が動かなければ、報告が差の原因だ。ここまで来て初めて、ベンダーが何をしたと主張しているかを読めばいい。

ベンダーに何を聞くか

4つの質問を、この順で。営業電話でもドキュメントサイトでも同じように効く。

結果を受け取る入力はあるか？ メモを書く場所のことではない。返ってきた結果が間違っていたと報告するための入口だ。
それは何に紐づくのか？ 答えか、記憶か、ステップか、保存された推測か。recall に関係するのは最初の2つだけだ。
それは何を変えるのか、そしてそれはどこに書いてあるのか？ テキストか、重みか、次回の読み出し順か。
この報告を送るのを誰が覚えていなければならないのか？ 答えが agent で、仕事が終わった後で、見ているものがない時だというなら——残りすべてをその前提で読めばいい。私たちの答えも同じだ。