fix(pipeline): bound embed batches by count times longest input, not by total [pipeline, poller, docs, tests]

[smileygames]

何を変えたか

Workers AI の batch embed の境界式を、input の合計から
input 件数 × batch 内の最長 input へ変更した。

根拠

4 件の拒否応答がいずれも input 件数で割り切れる。

commit	件数	報告値	商
1fb0f6b	18	60,678	3,371
bdf8b62	17	64,413	3,789
92eb94d	20	85,920	4,296
92eb94d	16	68,736	4,296

決定的なのは後ろの 2 行で、同一 commit を異なる件数で投げて 1 件あたりの商が
一致している。合計であれば、除外された 4 件が全て同一長でない限り起こらない。
endpoint は batch の各スロットを最長 input に padding し、その幅を件数分だけ
課金していると読める。

#236 / #242 / #244 が 3 回とも効かず、報告値が 1 token も動かなかったのは
このためである。合計は課金式に現れないので、単位を替えても縛る対象が違う。

変更点

• planEmbeddingBatches: 境界式を
  (件数) × max(utf8ByteLength(input) + TOKEN_OVERHEAD_PER_INPUT) <= budget へ。
  range の最長を伸ばす input は既存メンバー全体の課金幅を遡って広げるので、
  その手前で range を閉じる。単独超過 input を単独 batch にする guard は維持
• MAX_EMBEDDING_BATCH_BYTES（合計軸の予算）を退役。天井は
  WORKERS_AI_BATCH_CONTEXT_LIMIT 単一とし、planner の既定予算もこれにした
• 1 input の測定単位は UTF-8 バイト数のまま（fix(pipeline): bound embed batches by UTF-8 byte count, not character count #244 の上界は維持）
• src/poller.ts / src/poller.test.ts: 導出コメントを新しい式に更新
• docs/0-requirements.md / docs/0-requirements.ja.md を同一 PR で更新

判断: 並べ替えは行わない

padding モデルではサイズの近い input をまとめるほど効率が上がるが、
現在の planEmbeddingBatches は連続範囲 {start, end} を返し、呼び出し側が
files 配列を同じ境界で切ることで位置対応を保っている。並べ替えには返り値を
index 集合に変え、呼び出し側に置換を持たせる必要がある。

一方で poller の subrequest 予算が想定する最悪ケースは truncate 上限
（MAX_EMBEDDING_INPUT_CHARS）が決めており、詰め方では動かない。
call 数の削減は最悪ケースに効かないため、interface 変更のコストに見合わないと
判断し、順序維持の素朴実装を採った。

#240 の file 予算との整合

DIFF_SUBREQUESTS_PER_FILE = 3 の前提（1 batch 最低 2 file）は不変。
2 × 24003 = 48006 <= 60000 で成立する。等長 input の batch では
「件数 × 最長」と合計が厳密に一致するため、床を読み取る場面では
2 つの式が同じ値を返す。余裕が 75 中 74 まで詰まっている状況は変わらない。

テスト

• 4 観測の整数分解を固定する回帰テスト（同一 commit・2 件数で商が一致）
• 合計軸を通過し padding で天井を超える 18 file fixture
• 後続 input が padding を遡って広げるケースでの分割
• 1fb0f6b（20 file / 18 indexable）と 92eb94d（44 file）の embed 成功
• 既存の fix(pipeline): batch-embed diffs by token budget, not input count #236 / fix(pipeline): bound embed batches by character count, not estimated tokens [pipeline, poller, docs, tests] #242 / fix(pipeline): bound embed batches by UTF-8 byte count, not character count #244 fixture は維持（charge 関数のみ新モデルへ差し替え）

npm test = 350 tests pass / tsc --noEmit clean。

残る不確かさ

padding モデルは 4 観測からの推論であり確定ではない。確定させるには同一内容の
input を件数だけ変えて投げ、報告値が件数に比例するかを見る必要がある。
ただし本 PR の境界式は真の課金式が合計であっても上界として成立する
（合計 <= 件数 × 最長）ため、推論が外れていても安全側に倒れる。

Closes #246

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	github-rag-mcp	9daabab	Aug 15 2026, 01:18 AM

[smileygames]

AI self-review (execution mode: auto)

受け入れ条件

条件	結果
batch_size × max(入力コスト) が上限を超えない	pass — planEmbeddingBatches の閉じ判定が (i - start + 1) * widest > budget。emit される全 range に対して rangeCharge <= WORKERS_AI_BATCH_CONTEXT_LIMIT を assert
1fb0f6b / 92eb94d が embed に成功する	pass（テスト水準）— embed-diff.test.ts に両 commit の fixture。本番検証は deploy 後
4 観測の回帰テスト	pass — 4 件の整数分解、および同一 commit を 20 件 / 16 件で投げて商が 4,296 で一致する対を fixture 化
#240 file 予算が破綻していない	pass — poller.test.ts の minFilesPerBatch = floor(60000 / 24003) = 2。等長入力では合計軸と件数×最長が一致するため、この式は新モデル下でも妥当
watermark が 2026-08-11T15:33:02Z を越えて前進	未検証 — deploy 後の cron tick でのみ観測可能

制約

• 合計軸予算の退役: MAX_EMBEDDING_BATCH_BYTES は完全削除。リポジトリ全体を grep して残存参照ゼロを確認
• utf8ByteLength / TOKEN_OVERHEAD_PER_INPUT 維持: pass
• 単独超過入力の扱い: i > start guard により単独 batch として emit。欠落なし、無限ループなし（次反復で 2 * widest > budget により確実に閉じる）
• 順序対応: 並べ替えなし、range は連続かつ全入力を過不足なく被覆
• 要件記述の同一 PR 更新: docs/0-requirements.md / docs/0-requirements.ja.md を同梱

アルゴリズム検証

longest の不変条件を追跡した。else 分岐後は [start, i] 上の最大、if 分岐後（range を閉じた直後）は [i, i] 上の最大。反復 i で {start, end: i} を push する時点で、range [start, i) は反復 i-1 の判定を通過済みであり (i - start) * longest <= budget が成立している。単独超過入力のみが例外で、これは契約通り。

判断が分かれ得た点

issue が実装側に委ねた「index 集合への返り値変更」は行わなかった。並べ替えは呼び出し回数を減らすが、poller の subrequest 予算が見積もっている worst case は truncation cap で決まり packing 品質では決まらないため、予算軸に対しては何も買わない。判断理由は PR body と planEmbeddingBatches の doc comment に記録済み。

scope 逸脱

なし。変更は issue の target files 列挙内に収まっている。

次のステップ

auto モードにつき人間レビューは不要。self-review pass により直接 merge する。merge 後の Workers Builds 自動 deploy と、その後の cron tick での watermark 前進が実地の受け入れ判定となる。