「Hello」のためにLLMを呼ぶ価値はある？
Userがアプリを開いて入力します。
Hello
するとbackendが急に忙しくなります。
Historyを読む。Vector DBを検索する。Documentをrerankする。Promptを作る。高いmodelを呼ぶ。
そして返ってくるのは、
Hello! How can I help you today?
完璧です。
if文でもできそうな仕事のために、AI stack全員を起こしました。
AI Securityというと、普通はjailbreakやprompt injectionの話になります。
もちろんそれも大事です。
でもproductionでは、もう少し地味で現実的な役割もあります。
高い処理をする必要がないrequestを、早めに止めること。
全requestをLLMに会わせる必要はない
社内向けのHR assistantを作っているとします。
こんな3つのrequestが来ます。
Hello
2018年のワールドカップ優勝国は？
残っている有給休暇は何日？
全部同じpipelineに入れても動きます。
でも、
Hello
→ greeting
→ quick reply
World Cup
→ off-topic
→ fallback
有給休暇
→ valid
→ retrieval → LLM
でもいい。
最後のrequestだけが本当にRAGとmain modelを必要としています。
OpenAI Agents SDKでも、安いinput guardrailを高価なmodelの前に置く構成ができます。Blocking modeなら、guardrailが止めたrequestではmain modelもtoolも実行されません。
Amazon Bedrockはcostについてさらに分かりやすいです。
Guardrailがinput promptをblockした場合、Guardrail評価の料金は発生しますが、foundation model inferenceの料金は発生しません。
つまりSecurity Layerは、
「危険か？」
だけでなく、
「そもそもこいつを高いmodelまで通す必要ある？」
も判断できます。
正しい質問でも、全部同じmodelはいらない
例えば、
パスワードはどこで変更できますか？
と、
3カ国の育児休業制度を比較して、
法的リスクを分析し、根拠も出してください。
どちらも正しい質問です。
でも同じmodelが必要とは限りません。
全部frontier modelに送れば実装は楽です。
請求書にはあまり楽ではありません。
RouteLLM は、queryごとにstrong modelとcheap modelを選ぶrouterを研究しています。
Paperでは一部の設定で、response qualityを維持したまま2倍以上のcost削減を報告しています。
[RouteLLM — arXiv:2406.18665]
考え方はかなり普通です。
easy → cheap model
hard → strong model
そして "Hello" は、どちらも必要ないかもしれません。
もうダメだと分かっているoutputを最後まで生成しない
Output側も同じです。
長いresponseをstreamしていて、2文目の時点ですでにpolicy violationだと分かったとします。
それでも、
さらに生成...
さらに2000 tokens...
完成
→ moderation
→ 全部捨てる
という実装はできます。
Modelには最後まで話す権利があるらしいです。
NeMo Guardrailsでは、streaming outputをchunkごとにcheckできます。Railがblockすれば、その時点でstreamをterminateできます。
この方向のresearchもあります。
SentGuard はsentence単位でstreaming中のresponseをcheckします。Paperの実験では、unsafe caseの90.5%を2文以内に検出しました。
[SentGuard — arXiv:2606.02041]
StreamGuard はさらに、現在のpartial responseから「この先unsafeになりそうか」を予測して早めに介入しようとしています。
[StreamGuard — arXiv:2604.03962]
ただし、
streamを止めれば残りのtoken料金が必ず全部消える、という意味ではありません。
Providerのcancellationやbilling実装によります。
それでも考え方は単純です。
もう使えないと分かったoutputに、追加の処理をしない。
Guardrail自身が請求書になることもある
そして一番ありがちなやりすぎがこれです。
request
↓
LLM safety judge
↓
LLM topic classifier
↓
LLM intent classifier
↓
LLM router
↓
main LLM
↓
LLM output judge
User:
Hi
System:
「挨拶についてAI委員会で審議中です。」
Guardrailにもcostがあります。
Greetingならruleで十分かもしれない。
Intent分類ならsmall classifierで足りるかもしれない。
明らかなoff-topicならreasoning modelはいらない。
難しいcaseだけLLM judgeに回せばいい。
AI Securityは、何でもLLMで検査することではありません。
無駄な処理をどこで止めるかを決めることでもあります。
Prompt injectionならblock。
Off-topicならfallback。
簡単なtaskならcheap model。
怪しいtool callなら実行前に止める。
Outputがもうダメなら、さらに2000 tokenしゃべらせない。
Frontier modelは高いですが、それだけの価値があります。
本当に必要なときには。
AI Securityが守るのはdataやsystemだけではありません。
Productionではもう一つあります。
月末のAPI請求書です。
References
- RouteLLM: Learning to Route LLMs with Preference Data — arXiv:2406.18665
- SentGuard: Sentence-Level Streaming Guardrails for Large Language Models — arXiv:2606.02041
- Predict, Don't React: Value-Based Safety Forecasting for LLM Streaming — arXiv:2604.03962
- OpenAI Agents SDK — Guardrails
- Amazon Bedrock — How Guardrails works
- NVIDIA NeMo Guardrails — Output Rail Streaming