はじめに
最近、AI開発において**「どのLLMを使うか」以上に重要**だと感じているのが、LLMの周囲をどう設計するかです。
LLM APIを呼び出して回答を生成するだけであれば、比較的簡単に実装できます。
しかし、実際のサービスとして運用する場合には、
- 正しい情報を取得できるか
- Hallucinationを抑えられるか
- Agentが安全にToolを実行できるか
- モデルの出力をどのように評価するか
- LatencyやAPI Costをどう管理するか
といった問題を考える必要があります。
今回は、特に重要だと考えているRAG・AI Agent・Evaluationについて整理します。
1. RAGはVector Searchだけではない
基本的なRAGでは、次のような流れで回答を生成します。
User Query
↓
Embedding
↓
Vector Search
↓
Relevant Documents
↓
LLM
↓
Answer
シンプルな構成ですが、実際のデータを扱うと様々な問題が発生します。
例えば、
- 固有名詞を正確に検索できない
- 類似したDocumentが大量に取得される
- 本当に必要な情報がTop-Kに入らない
- 古いDocumentと新しいDocumentが混在する
- ユーザーがアクセスできないDocumentまで取得される
といったケースがあります。
そこで、より実用的なRAGでは、例えば次のようなPipelineを考えることができます。
User Query
↓
Query Rewriting
↓
Hybrid Search
(Vector Search + Keyword Search)
↓
Metadata Filtering
↓
Reranking
↓
Context Construction
↓
LLM
↓
Answer
個人的に特に重要だと考えているのが、Hybrid SearchとRerankingです。
Vector Searchは意味的に近い文章を探すことを得意としています。
一方で、
ERR_CONNECTION_TIMEOUT
のようなエラーコードや、製品番号、人名、会社名など、文字列そのものが重要な検索ではKeyword Searchが有効なケースがあります。
そのため、
Semantic Search + Keyword Search + Reranking
という構成にすることで、LLMへ渡すContextの品質を改善できます。
2. AI Agentは「何ができるか」より「何を許可するか」
AI Agentでは、LLMから外部のToolやAPIを利用できます。
例えば、
User
↓
AI Agent
↓
Tool Selection
├── Search Documents
├── Query Database
├── Call Internal API
└── Create Task
ここで重要なのは、単純にAgentへ多くのToolを与えることではありません。
「どの条件で、どのToolの実行を許可するか」
という設計が重要になります。
例えば、
search_customer
と
delete_customer
では、実行した場合のリスクが大きく異なります。
そのため、実運用では次のような制御が必要になります。
User Request
↓
Intent Analysis
↓
Tool Selection
↓
Permission Check
↓
Argument Validation
↓
Human Approval
↓
Execution
↓
Output Validation
特に考慮したいのは、
- Tool Schema
- Permission
- Input Validation
- Retry Limit
- Timeout
- State Management
- Human Approval
- Audit Log
などです。
AI Agentを高度にすることは、必ずしも**「すべてを自律的に実行させること」**ではないと考えています。
重要なのは、
どこまでAIに判断させ、どこから人間またはシステム側で制御するか
という境界を明確にすることです。
3. LLM Evaluationをどう考えるか
通常のプログラムでは、期待する結果を比較的明確に定義できます。
例えば、
assert calculate_total(100, 0.1) == 90
のようなTestを書くことができます。
しかし、LLMの場合は同じ質問でも表現の異なる回答が生成されるため、単純な文字列比較だけでは十分ではありません。
RAGであれば、例えば次のような項目を評価できます。
Retrieval
- Relevant Documentを取得できたか
- 必要な情報がTop-Kに含まれているか
- 不要なDocumentを大量に取得していないか
Generation
- ユーザーの質問に回答しているか
- Retrieved Contextに基づいて回答しているか
- Hallucinationが発生していないか
- Citationと回答内容が一致しているか
System
- Latency
- Token Usage
- API Cost
- Error Rate
- Task Completion Rate
つまり、単純な「正解・不正解」だけではなく、
Quality
+
Reliability
+
Latency
+
Cost
を継続的に確認する必要があります。
4. 「一番強いモデル」を使えばいいわけではない
LLMを選択するとき、
「どのモデルが一番性能が高いか？」
という比較をすることがあります。
しかし、Production環境では必ずしも最高性能のモデルをすべての処理に使用する必要はありません。
例えば、
Simple Task
↓
Small / Fast Model
Medium Complexity
↓
Balanced Model
Complex Reasoning
↓
High-Capability Model
High-Risk Action
↓
Human Approval
のように、Taskによってモデルを変更するModel Routingも考えられます。
ここで重要なのは、
このTaskに必要なQualityを、どのModelなら適切なLatencyとCostで実現できるか？
という視点です。
モデル単体ではなく、Quality・Latency・Costのバランスを見る必要があります。
5. Production AIでは「LLMの外側」が重要
AIアプリケーションを作り始めると、どうしてもModelやPromptに注目しがちです。
しかし、実運用ではLLMの外側にある仕組みも重要です。
User
↓
API
↓
Authentication / Authorization
↓
AI Orchestration
↓
Retrieval / Agent / Model
↓
Validation
↓
Response
+
Evaluation
Logging
Monitoring
Security
Cost Control
例えば、高性能なLLMを使用していても、Retrievalで間違ったDocumentを取得していれば、正確な回答を生成することは難しくなります。
Agentについても、Toolの実行権限が適切に管理されていなければ、Production環境で安全に利用することは難しくなります。
そのため、AIシステム全体を、
Retrieval → Generation → Validation → Evaluation → Monitoring
というPipelineとして考えることが重要だと思います。
まとめ
RAGやAI Agentを使って**「動くAI」**を作ることは、以前より簡単になりました。
一方で、**「実際に運用できるAI」**を作るためには、LLM以外の部分も設計する必要があります。
特に重要だと考えているのは、
- RAGでは検索品質そのものを設計する
- Hybrid SearchやRerankingを適切に利用する
- AgentではToolの権限と実行範囲を設計する
- LLMのOutputをValidationする
- Evaluationを継続的に実施する
- Quality・Latency・Costを同時に考える
という点です。
最近のAI開発ではモデル自体の性能が急速に向上しています。
だからこそ今後は、
「どのLLMを使うか」だけではなく、「LLMをどのようなシステムの中で使うか」
という設計力が、より重要になっていくのではないかと考えています。
今後、RAG、AI Agent、LLM Evaluation、Model Routingなどについて、実装例を含めながら書いていきたいと思います。