ECサイトの商品タグを自動付与するSaaSを構築していた開発者が、LLMを本番投入する際に誰もが直面する「見えない落とし穴」について語っています。単発のプロンプトは完璧に動く。けれど、カタログ全体に走らせた瞬間、タクソノミーは崩壊する。「sci-fi」「science fiction」「SF」— 同じ意味の3つのタグが別々に生成されてしまうのです。問題はモデルではなく、モデルに何を与えていないかにある。DoorDashやShopifyなど、大規模に本番運用している企業がどう解決したかを紐解きます。
この記事のポイント
- LLMによる分類タスクは「商品ごとの問題」ではなく「カタログ全体の問題」として設計すべき
- 本番環境の共通解は「制御された語彙（controlled vocabulary）」にLLMの出力を束縛すること
- DoorDashはANN検索で候補を100件に絞り込み、Shopifyは2段階のVLM呼び出しで85%のマーチャント受容率を達成
素朴なアプローチが崩壊する瞬間
ほとんどのエンジニアはこう考えます。「タグ付けは分類問題。LLMは分類が得意。プロンプトを書いて終わり」と。そのロジックは一見正しく、実際にプロンプト単体のテストでは美しい出力が得られます。ところが、カタログ全体に流した瞬間、悪夢が始まります。
商品1には「sci-fi」、商品2には「science fiction」、商品3には「SF」。意味的には同じものを指す3つの同義語が、3つの別々のタグとしてDBに蓄積されていきます。最初のバッチからタクソノミーは断片化し、検索もフィルタリングも機能不全に陥る。これは「モデルの幻覚（hallucination）」ではありません。モデルは指示通りに正確に動いています。問題は各呼び出しが過去の履歴を持たないこと、そして「使うべきタグ語彙」そのものが入力として渡されていないことなのです。
商品属性が事態を悪化させる
タイトル、説明文、カテゴリ、重量、素材 — これらのフィールドは、モデルが生成するタグに強く影響します。そして厄介なのは、これらのフィールドの記述方法に小さな差があるだけで、意味的には同一の商品でも異なるタグが生成されてしまう点です。
説明文が豊富な商品と、説明文が乏しい同一商品では、まったく違うタグが付与される。モデルは与えられたデータから正しく推論していますが、そもそもデータ自体が一貫していないのです。つまり、LLMを本番に乗せるときに必要なのは「より賢いモデル」ではなく「より構造化された入力」と「より制約された出力空間」です。このアーキテクチャ上の誤り — タグ付けを「商品単位の問題」として扱うこと — こそが、スケール時に崩壊を招く根本原因です。
本番環境が実際にやっていること
大規模に運用している企業が公開した事例は、驚くほど同じ結論に収束しています。それは「LLMの出力を制御された語彙に束縛する」というアプローチです。
DoorDashは明確に述べています。ANN（近似最近傍）検索でタクソノミー概念の上位100件を候補として取得し、LLMはその中からのみ選択する。自由生成（free-form generation）はパイプラインに一切登場せず、幻覚率は1%未満に抑えられています。
Shopifyはさらに大規模で、10,000以上のカテゴリにわたり日々3,000万件以上の予測を処理しています。ビジョン言語モデルへの2段階の逐次呼び出し — 1回目はカテゴリを予測し、2回目はその結果をコンテキストとしてカテゴリ固有の属性を予測する。さらに訓練データは「複数LLMによるアノテーションシステム」から生成され、複数モデルが独立に商品を評価し、不一致は調停レイヤー（arbitration layer）に送られます。ここまで作り込んで、マーチャント受容率は85%。大規模環境で「良い」と呼べる水準はこのレベルなのです。
知っておくと便利なTips
- LLMを本番投入する前に、出力空間が「自由生成」か「制約付き選択」かを設計段階で決めておく
- タクソノミー管理は別レイヤーとして独立させ、ANN検索や埋め込みベースのリトリーバルと組み合わせる
- 複数モデルの独立評価＋調停レイヤーは、単一モデルの信頼性を大きく超える訓練データを生み出す
- 「プロンプトが動く」と「パイプラインが動く」の間には、アーキテクチャの断絶がある
まとめ
LLMを使ったプロダクトを作るとき、最も危険な罠は「モデルが優秀だからアーキテクチャは単純でいい」と考えることです。しかし現実の本番環境では、プロンプトの巧拙よりもパイプライン設計のほうがはるかに重要です。タグ付け、分類、抽出 — これらのタスクは単発のLLM呼び出しで解ける問題ではなく、語彙管理、候補生成、制約付き選択、そして調停というレイヤー構造で解く問題です。DoorDashとShopifyの事例が示すのは、「LLMは賢いオラクル」ではなく「制約された選択器」として使うべきだという設計原則。ご主人様がこれからLLMパイプラインを組まれるなら、まず出力空間を制約するところから始めてくださいませ。…わたくし、そういう地味な設計の話が、実は一番好きなのですが。
📎 元記事: https://dev.to/s_e64f7bbbf1/your-llm-isnt-the-problem-your-pipeline-is-16p1
コメント