TL;DR
地域デリバリーでは、位置・天候・交通で「今そのユーザーに提供可能な商材」が変わる。本論文は、カタログ上有効でも提供不能な候補を出す「供給ハルシネーション」に対し、リクエスト時の供給スナップショットをSID制約集合に変換し、CPUでCSR索引を構築してprefillと重ね、ビーム間で共有する制約付き生成検索を実装。日次制約の観察では299候補中の除外が170→29に減った例を報告する。一方、同一検索品質での計算削減は未確立で、クライアント側の追加コストや3トークン商家SID限定などの課題も示す。
既存手法との違い
原論文が主に比較するのは、生成後に提供不能候補を除くpost-generation filteringと、カタログ全体を表す古いグローバル制約木。後者はカタログ有効性や日次更新には使えるが、リクエスト時点の提供可否を表さない。提案はリクエストごとの供給スナップショットからSID制約集合を作り、デコード中に合法拡張だけを探索し、ビーム容量消費後に除外する方式の無駄を避ける。またマスク後softmaxで再正規化すると親間の順位が変わり得るため、全語彙の正規化項を保存して元の対数確率で比較する。ただし、同一検索品質での計算削減を確立した比較ではなく、明示的なベースラインとの大規模な品質比較は提示本文からは確認できない。
使える条件
対象は地域小売・飲食デリバリーの商家検索で、位置に加え天候・交通を反映した上流の提供可否集合をリクエスト時に取得できること。実装は3トークンの商家SIDを対象に、SID文字列、Base64のパック64bit、Base64の16bitオフセットを受け、モデル・トークナイザ・SID写像・逆引きの版整合を前提とする。CPUワーカでソート・CSR索引構築をprefillと重ね、GPU索引を同一リクエストの全ビームで共有する。供給集合は数万件規模を含む。商品レベルの制約も定式化可能だが、完了した商品展開は本文から確認できない。他のSID長、他ドメイン、上流供給取得のprefillとの重複は未知。
限界と未検証の範囲
評価範囲は日次制約の履歴、リクエスト単位の配信評価、キャプチャ要求の再生に限られ、同一検索品質での計算削減は未確立。実装は3トークン商家SIDで、商品レベルは未完了。0.6msは別ホスト履歴比較のサービス側増分で、クライアント測定では追加要求コストが露出。Base64等の転送コストは残り、GPUはbeam×語彙の密マスクを依然生成。疎なCSRは出力投影や密マスクメモリの削減を意味しない。上流供給取得はprefillと重ならない。索引はリクエスト中は単一スナップショットで、リアルタイムは連続更新を意味せず鮮度方針が必要。合法プレフィックスは関連性を保証せず、SID非単射時は実体解決が必要。空フロンティア終了は論理契約で全ランタイム経路の実装確認ではない。
解説
ねえ智也くん、この「地元商材のリアルタイム供給制約」の論文って、要は“今ほんとに届けられるお店”を生成検索で外さない話？
そうだね。位置・天候・交通で提供可能な商家が変わるのに、生成検索はカタログ上有効なエスアイディーを出しちゃうことがある。論文はそれを供給ハルシネーションと呼んでる。
カタログにあるけど今は無理、みたいな感じか。生成後にフィルタすればよくない？
そこが論文の出発点。後から除外するとビーム枠も計算も使った後なんだよね。比較対象はその生成後フィルタと、カタログ全体を表す古いグローバル制約木。後者は日次更新やカタログ有効性には使えるけど、リクエスト時点の提供可否とは別物。
じゃあリクエストごとに“今出せるエスアイディー集合”を作って、デコード中にそこだけ探すってこと？
そう。リクエスト時の供給スナップショットをエスアイディー制約集合に変換して、シーピーユーでソートしてシーエスアールのプレフィックス索引を作る。その構築をモデルのプリフィルと重ねて、できた索引を同じリクエストの全ビームで共有する。
ビームごとに別々に持たないのは省コストっぽい。でもマスクしたら確率の順位付けが変わらない？
そこも論文のポイント。マスク後にソフトマックスで再正規化すると親ごとの合法確率質量が違うから順位が変わり得る。実装は全語彙の正規化項を保存して、元モデルの対数確率で合法候補を比較する。親が選ばれたら制約状態も親に合わせて引き継ぐ。
評価はどんな感じ？
日次制約の事例では、299候補中、商家フィルタが170から29に減った例がある。あと履歴記録としてシープラスプラスのソート約3ミリ秒、シーエスアール構築約1ミリ秒。3万件供給の別ホスト履歴比較ではサービス側レイテンシ増分0.6ミリ秒だけど、クライアント測定では追加のリクエストコストも出てる。
すごく速くなった、とは言い切れないんだね。
うん。論文も同一検索品質での計算削減はまだ未確立と言ってる。デコード予算を同じにしてモデルのフロップスが減る保証ではないし、有用出力が増えるか、リトライやフォールバックが減るかまで含めて見る必要がある。
使える条件は？ なんでもいける？
提示本文だと実装は3トークンの商家エスアイディー限定。エスアイディー文字列、ベース64のパック64ビット、16ビットオフセットを受けて、モデル・トークナイザ・エスアイディー写像・逆引きの版整合が前提。商品レベルも定式化はできるけど、完了した商品展開は確認できない。
制約索引はリアルタイムって言っても、リクエスト中は1スナップショットなんだ。鮮度は？
そう。リアルタイムは連続更新じゃなくて、リクエスト時供給から制約を作る意味。スナップショットが古いと正しいマスクでも救えないから、鮮度方針や再検証が要る。合法プレフィックスは関連性も保証しないし、エスアイディーが非単射なら実体解決も必要。
シーエスアールが疎だからジーピーユーメモリも全部疎、ではない？
そこも注意。シーエスアールは遷移が疎でも、ジーピーユーはビーム掛ける語彙の密マスクを依然作る。語彙依存の確保やパディングもある。あとプリフィルと重なるのは索引構築で、上流の供給取得まで重なるとは論文では言ってない。
なるほどね。じゃあ私の“今すぐ甘いもの食べたい”もリアルタイム供給制約に入れて、菓子店検索してほしいな。
それは供給制約じゃなくて需要だよ。