はじめに

最近、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などについて、実装例を含めながら書いていきたいと思います。