プロンプトから製品へ:LLM を本物のアプリに変える

プレイグラウンドで機能するプロンプトはデモであって、製品ではない。この二つの間の隔たりこそ、ほとんどのAIプロジェクトが静かに死んでいく場所だ。本物のユーザーに耐える LLM アプリケーションを構築することは、デモが示唆するほど巧みなプロンプト作成とは関係がなく、それよりはるかに、ありふれたソフトウェアの規律と関係がある。私たちはこの種のものを十分に届けてきた。Youp、MadaiOps、そして今は Linea。だから何が実際にその隔たりを埋めるのかについて意見を持っている。そのどれもが華やかではない。

罠は、最初のバージョンが完成しているように感じられることだ。巧妙なプロンプトを貼り付けると、モデルは印象的な何かを返し、それをUIで包んでローンチと呼びたくなる。それから本物のユーザーが、あなたが想像もしなかった入力を携えてやってくる。モデルは自信満々に間違ったことをし、あなたは自分の修正が事態を良くしたのか悪くしたのかを知る手立てがないことに気づく。この記事は、その印象的なデモを、本番で運用でき、夜通しぐっすり眠れる何かに変える足場についてだ。

プロンプトではなく、評価から始める

早い段階で構築できる最もレバレッジの高いものは、評価セットだ。ベンチマークでもリーダーボードでもない。良い出力がどう見えるかと対にした、本物の入力のフォルダだ。20個の例はゼロに勝り、厳選された50個は、かき集めた1000個に勝る。

理由は単純だ。評価があれば、プロンプトエンジニアリングは雰囲気であることをやめる。一行変え、セットを走らせ、数字が動くのを見る。それなしでは、あらゆる微調整は迷信だ。私たちは、チームが一週間かけてプロンプトを改善した挙げ句、何ヶ月も前に解決していたケースで退行するのを見てきた。彼らが見ていなかったケースを、何も測定していなかったからだ。

私たちが固く抱いている意見をいくつか挙げる。

言い回しではなく、成果で採点せよ。 構造化されたもの（抽出、分類、ルーティング）については、文字列の類似度ではなく、パースされた結果に対してアサートせよ。自由形式のテキストについては、厳密なルーブリックを備えた LLM-as-judge で構わないが、まず人間のラベル数個に対して審判を検証せよ。さもないと、あなたは単に一つのモデルの好みを測定しているにすぎない。
退行ファイルを保つ。 すべての本番障害は、恒久的なテストケースになる。これこそが評価セットを正直に保つ方法だ。それは現実が押してくる方向にぴったりと成長する。
評価をプロンプトとともにバージョン管理せよ。 評価セットを伴わないプロンプトは、テストされていないコード変更だ。

この記事から一つだけ構築するなら、これを構築せよ。下流のすべては、次の問いに答えられることに依存している。あれは事態を良くしたのか?

ガードレールは謝罪より安い

モデルは、ありふれたソフトウェアがしない仕方で失敗する。存在しないAPIを発明し、ユーザーの誤った前提に同意し、幻覚のフィールドを含む一見妥当なJSONを吐き出す。ガードレールは、これがユーザーに、あるいはもっと悪いことに実行ステップに届く前に、それを捕らえる層だ。

三つの位置で考えよ。

入力ガードレール は、モデルが走る前に拒否またはサニタイズする。プロンプトインジェクションのスクリーニング、PIIのマスキング、トピック外のフィルタリング。
出力ガードレール は、返ってくるものを検証する。スキーマ検証、引用の根拠づけチェック、ポリシーフィルタ。
アクションガードレール は、モデルと副作用を持つ何かとの間に座る。

三つ目こそ、本物のリスクが宿る場所だ。私たちのワークフロー自動化エージェントである Linea では、モデルはアクションを提案できる。APIを呼ぶ、レコードを移動する、メッセージを送る。提案と実行は、意図的に別々のステップになっている。結果を左右するすべてのアクションは、何かが走る前に、型付き契約とポリシーチェックを通過し、破壊的または不可逆なアクションには明示的な確認ゲートが必要だ。エージェントが誤ったことを提案するのは、反復して直せるUXの問題だ。エージェントが誤ったことを 実行する のは、インシデントだ。この二つの障害モードを、固い境界の反対側に保て。

意見の強い版はこうだ。構造化出力をスキーマに対して検証し、失敗時にはモデルが一貫していると信じるのではなくリトライせよ。そして、モデルの生の出力を、不可逆なアクションを引き起こすものにしては決してならない。その間には、常に決定論的なチェックを置け。

レイテンシとコストを機能のように予算化する

レイテンシとコストは、最後に測定するものではない。それらは最初から設計時に対峙する制約だ。なぜなら、それらは請求書だけでなく、アーキテクチャを変えるからだ。

ユーザーに面するアクションごとに明示的な予算を設定せよ。p95 レイテンシの目標と、コール当たりのコスト上限。それらがひとたび書き留められれば、設計上の決定は容易になる。私たちが繰り返し手を伸ばすパターンをいくつか挙げる。

ステップごとにモデルのサイズを最適化せよ。 ほとんどのパイプラインには、本当にフロンティアモデルを必要とする一つか二つのステップと、より小さく速いモデルで問題なく処理できるいくつかのステップがある。単純な分類を安価なモデルにルーティングし、高価なモデルを難しい推論ステップのために取っておくことは、利用可能な最も見返りの高い最適化であり、たいていレイテンシも改善する。
最初のトークンをストリーミングせよ。 会話的なものなら何であれ、体感レイテンシは最初のトークンまでの時間に支配される。四秒かかるストリーム応答は、二秒かかるブロッキング応答より心地よく感じられる。
積極的にキャッシュせよ。 安定したシステムコンテキストにはプロンプトキャッシュを、繰り返される入力には通常の結果キャッシュを。本番トラフィックの意味ある割合は、ほぼ重複だ。

頭に留めておくべきトレードオフはこうだ。より大きなモデルはエンジニアリングの労力を減らすが、限界コストとレイテンシを永遠に上げる。より安価なモデルはあなたに仕事を押しつける。より丁寧なプロンプト、より多くのガードレール、より多くの評価。だがその仕事は、恒久的な節約に対する一度きりのコストだ。量のあるものなら何であれ、エンジニアリングに投じよ。

意図的に、人間をループに残す

「人間をループに（human in the loop）」はあまりに頻繁に言われるので、何も意味しなくなった。うまくやれば、それはAIが失敗したときの予備策ではなく、設計された役割分担だ。問いは人間を含めるべき かどうか ではなく、人間の判断が、それが加えるレイテンシよりも価値を持つのはどこか だ。

私たちに最もよく役立ってきたパターンは、信頼度でゲートした段階的エスカレーション だ。システムは自信のある多数派を自動で処理し、不確実な少数派を人間へルーティングする。モデルの推論を添えて、人間が数分ではなく数秒で判断できるようにする。MadaiOps では、通常のパラメータ内の注文オペレーションは流れて通過し、異常なものは何であれ、静かに実行されるのではなく、コンテキストとともにオペレーターへ浮かび上がる。レビュアーは機械のお守りをしているのではない。彼らは自分の注意を、それが希少で価値のある場所にだけ費やしているのだ。

もう一つのルール。人間の修正を計測し、それを評価セットとプロンプトへフィードバックせよ。人間から学ばない human-in-the-loop システムは、同じ仕事に二度支払っているだけだ。

自動化すべきでないものを知る

この規律における最も難しい判断は、自制だ。すべてのタスクをモデルに委ねるべきではないし、成熟とは、どれをそのままにしておくべきかを知ることだ。

私たちのおおまかなテストはこうだ。ミスのコストが低いか、ミスが検出して元に戻すのが容易な場所で自動化せよ。 下書き、要約、抽出、分類、ルーティング。良い候補だ。誤った下書きは編集され、誤った要約は読めば捕まる。エラーが高価で、検出が難しく、あるいは不可逆な場所では、はるかに慎重であれ。お金を動かすもの、取り消せないコミュニケーションを送るもの、法的または医療的な判断を下すもの、何であれ。そこでは、モデルは補助的な役割に属する。選択肢を浮かび上がらせ、レビューのための下書きをする。運転席に座るのではなく。

私たちが守る一線はこうだ。モデルが間違っていることをどう捕らえるかを説明できないなら、あなたはそのステップを自動化する準備ができていない。 失敗を検出する能力こそが本当の前提条件であり、精度そのものよりも重要だ。完全に検証できる精度95%のステップは、検証できない精度99%のものより、届けるのに安全だ。

仕事のかたち

プロンプトを製品に変えることは、大部分が華やかでない部分だ。測定できるようにするための評価、失敗を封じ込めるためのガードレール、速く手頃であり続けるための予算、判断が重要な場所に配置された人間、そして一部を自動化せずに残す規律。モデルはおそらくシステムの二割にすぎない。残りの八割は、その時折の見事さを頼りにするのを安全にするエンジニアリングだ。

朗報は、これが馴染みのある仕事だということだ。それは、あらゆる種類の良いソフトウェアを作るのと同じ本能に報いる。変える前に測定せよ、爆発半径を封じ込めよ、ユーザーの時間を尊重せよ。モデルは新しい。だが、その職人技は新しくない。