システム設計 GenAI: 本番アプリケーションの基盤とアーキテクチャ
LLM をアプリケーションに統合しようとしていて、RAG を実行するか、微調整を実行するか、それとも単純に実行するか迷っています。 プロンプトを改善しますか？あなたは一人ではありません: 分析によると、2024 年までに、 GenAI 導入の 73% は 企業が失敗する 6 か月以内。主にフェーズでのアーキテクチャの選択が間違っていたため イニシャルのデザイン。問題はモデルではありません。多くのチームが最初にテクノロジーを選択していることです 問題を理解してください。
このガイドでは、本番環境で GenAI システムを設計するための実践的な意思決定フレームワークを提供します。 基本的なアーキテクチャ — RAG、微調整、プロンプト エンジニアリング — とアプローチを選択する基準 特定のユースケースに最適です。
何を学ぶか
- 3 つの基本アーキテクチャ: RAG、微調整、およびプロンプト エンジニアリング
- 意思決定の枠組み: 各アプローチをいつ使用するか
- 本番環境での GenAI アプリケーションのシステム アーキテクチャ
- テクノロジー スタック 2026: LangChain、LlamaIndex、vLLM
- よくあるパターンと避けるべきアンチパターン
- RAG システムを評価するための品質指標
73% の問題: GenAI の導入が失敗する理由
建築に入る前に、なぜこれほど多くのプロジェクトが失敗するのかを理解することが重要です。原因 エンタープライズ展開の事後分析で特定された主なものは次のとおりです。
- 管理されていない幻覚: モデルはもっともらしいが誤った答えを生成しますが、何も生成しません。 検証システムが導入されました
- 許容できない遅延:p99 ユーザーが期待するクエリの 3 ～ 5 秒を超える 速い
- 爆発的なコスト: 本番稼働前はクエリごとのコスト計算は不要で、その後は 予算は数週間で消費されてしまう
- 管理されていない知識の遮断: モデルは最近のデータやプライベート データを知りません。 会社の
- トレーサビリティの欠如: 文書がどの文書に基づいているかを知ることは不可能 対応（規制された状況では重要）
これから説明する各アーキテクチャは、これらの問題の一部に他のものよりもうまく対処します。を知る トレードオフにより、最初から堅牢なシステムを設計できます。
3 つの基本アーキテクチャ
1. 迅速なエンジニアリング
GenAI システムの出発点: モデルを次の方向に導くためのプロンプトを構造化します。 希望の出力。 2026 年の主要な手法:
- 数発のプロンプト: プロンプトで入出力の例を提供します。
- 思考の連鎖 (CoT): 最初にモデルに段階的に考えるように依頼します。 答える
- システムプロンプト: モデルの動作とコンテキストを定義します。
- 構造化された出力: 信頼性の高い解析のために出力を JSON または XML 形式に強制します
# Esempio: prompt engineering con structured output
import json
from openai import OpenAI
client = OpenAI()
def analyze_ticket(ticket_text: str) -> dict:
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "system",
"content": """Sei un sistema di triage per ticket di supporto.
Analizza il ticket e restituisci JSON con:
- priority: "high" | "medium" | "low"
- category: "bug" | "feature" | "question"
- sentiment: "frustrated" | "neutral" | "positive"
- estimated_resolution_hours: numero intero"""
},
{
"role": "user",
"content": f"Ticket: {ticket_text}"
}
],
response_format={"type": "json_object"}
)
return json.loads(response.choices[0].message.content)
# Uso
result = analyze_ticket("Il mio account e bloccato da ieri, non riesco ad accedere!")
# {"priority": "high", "category": "bug", "sentiment": "frustrated", ...}
いつ使用するか: シンプルで明確に定義されたケース、ラピッド プロトタイピング、 統合されるプライベート データと基本モデルはすでにドメインを知っています。
限界: 最近のデータや独自のデータでは機能しません。事実に対する幻覚 具体的であり、コストはコンテキストの長さに比例します。
2. RAG — 検索拡張生成
RAG は、知識の遮断と個人データの問題を解決します。 モデルの知識、関連するドキュメントをデータベースから取得し、コンテキストに配置します。 世代以前。
RAG システムの基本アーキテクチャには 4 つのフェーズがあります。
- インデックス作成: ドキュメントはチャンクに分割され、埋め込みベクトルに変換されます。 そしてベクトルデータベースに保存されます
- 検索: ユーザーのクエリは同じ埋め込み空間に変換されます 最も類似したチャンクが復元されます
- 増強: 取得されたチャンクがコンテキストとしてプロンプトに挿入されます。
- 世代: LLM は、提供されたコンテキストに基づいて応答を生成します。
# RAG minimo funzionante con LangChain e Qdrant
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_qdrant import QdrantVectorStore
from langchain.chains import RetrievalQA
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
# 1. Carica e chunka i documenti
loader = PyPDFLoader("manuale_prodotto.pdf")
docs = loader.load()
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=64
)
chunks = splitter.split_documents(docs)
# 2. Crea il vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = QdrantVectorStore.from_documents(
documents=chunks,
embedding=embeddings,
url="http://localhost:6333",
collection_name="manuale_prodotto"
)
# 3. Crea la chain RAG
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
rag_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=retriever,
return_source_documents=True
)
# 4. Query
result = rag_chain.invoke({"query": "Come configuro le notifiche email?"})
print(result["result"])
# La risposta cita i documenti recuperati, non inventa
いつ使用するか: 企業ナレッジベース、技術文書、FAQ、その他 応答が特定の追跡可能な文書に基づいている必要がある場合。
限界: 品質は取得品質に依存し、追加のレイテンシー、 インフラストラクチャのオーバーヘッド。
3. 微調整
微調整は、データの追加トレーニングを通じてモデルの動作を適応させます。 ドメイン固有。 2026 年の支配的なパラダイムは、 パラメータ効率の高い微調整 (PEFT) LoRA や QLoRA などの技術を使用して、消費者向けハードウェアでのトレーニングを可能にします。
# Fine-tuning con LoRA usando transformers e PEFT
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model, TaskType
import torch
model_name = "meta-llama/Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
model_name,
torch_dtype=torch.bfloat16,
device_map="auto"
)
# Configurazione LoRA: adatta solo il 0.1% dei parametri
lora_config = LoraConfig(
task_type=TaskType.CAUSAL_LM,
r=16, # rank della matrice di adattamento
lora_alpha=32, # scaling factor
lora_dropout=0.1,
target_modules=["q_proj", "v_proj", "k_proj", "o_proj"]
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# trainable params: 6,815,744 || all params: 8,037,191,680
# trainable%: 0.0848%
いつ使用するか: 何千ものトレーニング例がある場合、次の形式が必要になります。 非常に具体的で一貫性のある出力、または例を削除してプロンプトの長さを短縮したい場合 数ショット。
重大なアンチパターン: 事実の知識を注入するために微調整しないでください (日付、数字、具体的な事実)。モデルは理解も幻覚もなく「記憶」する とにかく。知識については RAG を使用してください。
意思決定の枠組み
最も重要な質問は、「どのテクノロジーを使用するか」ではなく、「私の本当の問題は何なのか」です。 このデシジョン ツリーはユースケースの 90% をカバーします。
Hai dati privati o recenti che il modello non conosce?
SI --> Considera RAG come base
NO --> Prompt engineering puo essere sufficiente
Il tuo knowledge base e aggiornato frequentemente?
SI --> RAG (indicizza i nuovi documenti, non ri-addestra)
NO --> Fine-tuning puo essere considerato
Hai 1000+ esempi di coppie input-output di alta qualita?
SI --> Fine-tuning e un'opzione valida
NO --> Stai nei limiti di RAG + few-shot
Hai bisogno di tracciabilita (citare le fonti)?
SI --> RAG obbligatorio
NO --> Piu flessibilita
Latenza critica (sotto 500ms)?
SI --> Fine-tuning (elimina retrieval overhead) o caching aggressivo
NO --> RAG funziona bene
Conclusione tipica 2026:
Start with RAG + prompt engineering
Add fine-tuning solo se RAG non raggiunge qualita richiesta
本番環境向けのシステムアーキテクチャ
実稼働グレードの GenAI システムは、単なる「LLM + ベクトル データベース」をはるかに超えています。コンポーネント 本格的な展開には必要です:
# Stack minimo per RAG in produzione (Docker Compose)
services:
api:
image: your-genai-api:latest
environment:
OPENAI_API_KEY: ${OPENAI_API_KEY}
QDRANT_URL: http://qdrant:6333
REDIS_URL: redis://redis:6379
depends_on:
- qdrant
- redis
qdrant:
image: qdrant/qdrant:v1.9.0
volumes:
- qdrant_storage:/qdrant/storage
ports:
- "6333:6333"
redis:
image: redis:7-alpine
# Semantic cache: evita LLM calls per query simili
volumes:
- redis_data:/data
prometheus:
image: prom/prometheus:latest
# Monitora: latency p50/p95/p99, costo per query, quality score
grafana:
image: grafana/grafana:latest
# Dashboard: LLM performance, retrieval quality, cost tracking
プロトタイプと運用システムを分ける重要なコンポーネントは次のとおりです。
- セマンティックキャッシング (Redis + GPTCache などのライブラリ): コストを 30 ～ 60% 削減 同様の繰り返しクエリがあるアプリケーションの場合
- 可観測性: 遅延、使用されたトークン、コスト、および各 LLM 呼び出しを追跡します。 品質スコア — このデータがなければ最適化できません
- フォールバック戦略: OpenAI がダウンするとどうなりますか?ローカルモデルがある バックアップ方法は？
- レート制限とクォータ管理: 予算をクエリから守ります 異常な
- PII の検出: LLM にデータを送信する前に、個人データを検出して隠蔽します 敏感な
2026 年のテクノロジースタック
GenAI エコシステムは、いくつかの有力なプレーヤーを中心に安定しています。
推奨スタック 2026
- オーケストレーション: 複雑な RAG パイプラインの場合は LangChain v0.3+ または LlamaIndex v0.10+。 エージェントワークフロー用の LangGraph
- ベクターデータベース: Qdrant (自己ホスト型、優れたパフォーマンス)、pgvector (すでに PostgreSQL、100 万ベクトル未満）、Pinecone（マネージド、レイテンシ保証）
- 推論: セルフホスト型オープンソース モデルの場合は vLLM または TensorRT-LLM。 OpenAI/人類学 クラウドAPI用
- 埋め込み: OpenAI による text-embedding-3-small (1536 ディメンション、$0.02/1M トークン) または 無料のセルフホスティング用 all-MiniLM-L6-v2
- 可観測性: トレース用の LangSmith、Weights & Biases Weave、または Phoenix チェーンの
- 評価: 自動化された RAG メトリクスの RAGAS (忠実度、回答の関連性、 コンテキストを思い出す)
RAG システムの品質指標
RAG システムが正常に動作しているかどうかを確認するにはどうすればよいですか? RAGAS フレームワークは、測定可能な指標を定義します。
# Valutazione automatica con RAGAS
from ragas import evaluate
from ragas.metrics import (
faithfulness, # la risposta e supportata dai documenti recuperati?
answer_relevancy, # la risposta risponde alla domanda?
context_recall, # i documenti recuperati contengono le info necessarie?
context_precision # i documenti recuperati sono tutti rilevanti?
)
from datasets import Dataset
# Dataset di test (ground truth necessario)
test_data = {
"question": ["Come configuro l'autenticazione 2FA?"],
"answer": ["Per configurare 2FA, vai in Impostazioni > Sicurezza..."],
"contexts": [["Documentazione 2FA: ...", "Guida sicurezza: ..."]],
"ground_truth": ["La 2FA si configura tramite l'app mobile nelle impostazioni sicurezza"]
}
dataset = Dataset.from_dict(test_data)
result = evaluate(dataset, metrics=[
faithfulness,
answer_relevancy,
context_recall,
context_precision
])
print(result)
# faithfulness: 0.95 (la risposta non inventa)
# answer_relevancy: 0.88 (la risposta e pertinente)
# context_recall: 0.82 (i doc recuperati coprono la risposta)
# context_precision: 0.91 (i doc recuperati sono rilevanti)
実稼働システムの現実的な目標: 忠実度 > 0.85 (重要: これ未満) 閾値幻覚は頻繁にあります）、answer_relevancy > 0.80、context_recall > 0.75。
避けるべきアンチパターン
- すべてのドキュメントの固定チャンク サイズ: 構造化ドキュメント (FAQ、API ドキュメント) 説明文以外のチャンク化が必要
- セマンティック検索のみ: 厳密な専門用語では失敗します。ハイブリッド検索を使用する (BM25 + セマンティック)
- 再ランキングなし: 上位 k 個のベクトルが必ずしも最も有用であるとは限りません。ある クロスエンコーダーにより精度が 15 ～ 20% 向上
- 継続評価を行わない RAG：ドキュメントを保存すると品質が低下します。 彼らは変わります。生産時の忠実度を監視します
- 第一選択としての微調整：そして高価で遅い。 RAGはほぼ常にそこにあります 右に移動して開始します
結論と次のステップ
GenAI アプリケーションのシステム設計には、はるかに幅広いアーキテクチャ上の選択が必要です。 モデルの選択。 2026 年の経験則: 常に RAG + プロンプトで始まります エンジニアリング、RAGAS で品質を測定し、ギャップがある場合にのみ微調整を追加します。 検索の最適化後も品質は維持されます。
このシリーズの次の記事では、各コンポーネントを詳しく説明します。 右ベクトル データベース、チャンキング戦略、ハイブリッド検索、およびエージェント アーキテクチャを備えた ランググラフ。