大きなライブラリでの検索が再び動くようになりました
一部の大きなアカウントでは、Tatsulok の検索が実行するたびに失敗していました。今は、ライブラリをページごとに読み、上限に達したらどこで止まったかを記録します。何が壊れていたか、何が変わったか、何がまだ上限付きかを説明します。
更新日
大きなライブラリでは何が壊れていたのか
問題を報告したあるアカウントでは、ライブラリの検索が一度の実行で28,430件の文書を読んでいました。Tatsulok がデータベースとして使う Convex は、1回のクエリまたはミューテーションの実行で読めるデータを 16 MiB までに制限しています。検索はその上限を超えて失敗していました。PR #9771 に記録された計測（2026年8月3日マージ）では、8回中8回が失敗し、1回あたり4.0秒から5.6秒で止まっていました。
失敗はランダムではありませんでした。同じ処理が毎回同じように失敗していました。だから大きなライブラリを持つ人には、障害のように見えていました。
上限を上げるのではなく、ページごとに読む理由
16 MiB の上限は実行ごとにかかります。大きなライブラリの検索には、その実行が複数必要です。そこで候補の一覧を複数の実行にまたがって作るようにしました。各ページは行数ではなく、読んだバイト数で区切ります。行が大きくなると行数は上限の目安になりません。ここで扱う行は、文書1件まるごとを含むことが多いからです。
守るべき規則が一つあります。Convex が「途中の可能性がある」と示したページを、完全なものとして受け入れることはしません。範囲を狭めて読み直すか、読み取りが打ち切られたことを記録します。
もう一つの失敗: 1回の答えに要素が多すぎた
同じ検索は、別の種類のエラーでも失敗していました。関数が返せる配列の要素は 8,192 個までです。ある呼び出しは 21,849 件の ID を返そうとしていました（2026年8月3日マージの PR #9716 に記録）。今回の修正では、ID を 1 要素あたり 250 件のまとまりにして詰めます。上限は文書の数ではなく、まとまりの数を数えるようになり、約 205 万 ID まで広がります。回帰テストは 21,849 件という実際の数を使うので、詰めずに返す形に戻すとテストが失敗します。
今の検索が記録すること
他の人が共有したライブラリを検索するとき、読み取りには予算があります。予算に達すると読み取りを止め、検索はその範囲が打ち切られたことを記録します。途中までの一覧を完全な結果のように返すことはしません。正確検索の経路では、検索ツールがスキャンはライブラリ全体を覆っていないとアシスタントに伝えるので、回答でもそう言えます。
FAQ
- 一部のアカウントで検索が失敗していたのはなぜですか？
- 1回の実行で、Convex の上限 16 MiB を超えるデータを読んでいたためです。大きなライブラリはその上限を超え、該当するアカウントでは毎回失敗していました。
- 今は、ライブラリ全体を必ず読めるようになりましたか？
- いいえ。ページごとに読むので、1回の読み取りの大きさはライブラリの大きさに左右されなくなりました。ただし上限に達すると検索は途中で止まります。止まったことは記録され、隠されません。共有ライブラリの一覧には1回の検索で 250 件までという上限があり、その切れ目はまだ記録されていません。
- 検索に文書が出てこないときは、どうすればよいですか？
- その文書は自分で開いて、該当する一文を探してください。検索結果が少ないことは、文書がないことの証明にも、存在しないことの証明にもなりません。元の文書を読んで判断するまで、検索結果は出発点として扱ってください。
- 引用の仕組みは変わりましたか？
- 変わっていません。引用をタップすると、元の文書の該当箇所が開きます。今回の変更は、回答の前に検索がどの文書を候補にできるかに関わります。
- この上限の根拠はどこで確認できますか？
- Convex は公式ドキュメントで上限を公開しています。1回のクエリまたはミューテーションで読めるデータは 16 MiB、配列の要素は 8,192 個までです。出典にリンクを載せています。
