5.1 LLM选择与配置

subgraph "LLM 选型关键维度"
    S1[生成质量]
    S2[推理速度]
    S3[API 成本]
    S4[上下文窗口]
    S5[中文能力]
end
​

</div>

### RAG 场景的 LLM 选型决策框架

| 场景 | 推荐模型 | 理由 |
|------|---------|------|
| 高质量问答（客服、知识助手） | GPT-4o / Claude 3.5 Sonnet | 生成质量最高，忠实度好 |
| 成本敏感（内部工具、大量请求） | GPT-4o-mini / Qwen2-7B | 成本低 10-50 倍，质量够用 |
| 隐私要求（数据不出内网） | Qwen2-72B / DeepSeek-V2（本地部署） | 完全可控，无数据外泄 |
| 超长文档（整篇论文/合同问答） | Claude 3.5 Sonnet / Gemini 1.5 Pro | 200K+ 上下文窗口 |
| 高并发低延迟 | GPT-4o-mini / Llama-3-8B | 推理速度快，支持高并发 |

**核心判断依据**：在实际选型中，我建议先做一轮快速评测：用 10-20 个真实查询分别跑 2-3 个候选模型，对比生成质量、延迟和成本，再用数据驱动最终决策。先确定你的首要约束是质量、成本还是延迟，再按上表选型。需要强调的是，不存在"全能最优"的模型——GPT-4o 质量好但贵，本地模型便宜但需要运维。选型就是在这三者之间找到最适合你业务的平衡点。

## 环境准备

```python
# OpenAI SDK（兼容 OpenAI API 格式的模型）
pip install openai>=1.0.0

# LangChain LLM 集成
pip install langchain>=0.3.0
pip install langchain-openai>=0.2.0

# 本地模型推理
pip install vllm>=0.5.0    # 高性能推理引擎
# pip install ollama       # 简易本地推理
​

前置知识：大语言模型基本概念、API 调用基础、Python 异步编程。

分步实战

步骤 1：使用 OpenAI SDK 集成 LLM

OpenAI SDK 已成为 LLM API 调用的事实标准。多数模型提供商（如 DeepSeek、Qwen、Moonshot）都兼容 OpenAI API 格式。

from openai import OpenAI
from typing import List

# 标准 OpenAI
client = OpenAI()  # 自动读取 OPENAI_API_KEY

# 兼容 OpenAI 格式的第三方模型
# client = OpenAI(
#     api_key="your-key",
#     base_url="https://api.deepseek.com/v1",  # DeepSeek
# )


def generate_rag_answer(
    query: str,
    contexts: List[str],
    model: str = "gpt-4o-mini",
    temperature: float = 0.1,
    max_tokens: int = 2000,
) -> str:
    """
    RAG 标准调用：将检索到的上下文和用户查询一起发给 LLM。
    
    Args:
        query: 用户问题
        contexts: 检索到的文档片段列表
        model: 模型名称
        temperature: 生成温度（RAG 场景建议 0-0.3）
        max_tokens: 最大生成长度
    """
    # 构建上下文文本
    context_text = "\n\n".join(
        f"[文档 {i+1}]\n{ctx}" for i, ctx in enumerate(contexts)
    )
    
    system_prompt = """你是一个专业的知识库问答助手。请根据提供的参考文档回答用户问题。

规则：
1. 只基于参考文档中的信息回答，不要编造文档中没有的内容
2. 如果文档中没有足够信息回答问题，请明确说明
3. 回答时引用来源（如"根据文档 1"）
4. 使用清晰的结构化格式"""

    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": f"参考文档：\n{context_text}\n\n用户问题：{query}"},
        ],
        temperature=temperature,
        max_tokens=max_tokens,
    )
    
    return response.choices[0].message.content
​

temperature 的选择：这是 RAG 场景中最重要的 LLM 参数。

• temperature=0：完全确定性输出，同一输入永远得到相同回答。适合事实型问答（"XX 的价格是多少"）
• temperature=0.1-0.3：轻微随机性，适合大多数 RAG 场景。让回答更自然但不失控
• temperature>0.5：不推荐用于 RAG。高温度会增加幻觉概率，因为模型更倾向于"创造"而非"复述"

我的建议：RAG 场景默认用 temperature=0.1。如果你发现回答太机械，可以微调到 0.2，但很少需要超过 0.3。

步骤 2：使用 LangChain 集成 LLM

LangChain 作为目前最流行的 LLM 应用开发框架，提供了更高级的抽象，适合构建复杂的 RAG Pipeline：

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

# 初始化 LLM
llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0.1,
    max_tokens=2000,
    # 超时和重试配置
    timeout=30,
    max_retries=2,
)

# 定义 Prompt 模板
prompt = ChatPromptTemplate.from_messages([
    ("system", """你是 {domain} 领域的专业问答助手。
请严格基于以下参考文档回答问题。如果文档中没有相关信息，请直接说明。

参考文档：
{context}"""),
    ("user", "{question}"),
])

# 构建链式调用
rag_chain = prompt | llm | StrOutputParser()

# 使用
answer = rag_chain.invoke({
    "domain": "技术",
    "question": "FAISS 的 HNSW 索引适合什么规模的数据？",
    "context": "FAISS 的 HNSW 索引在 10 万到 1000 万条数据上表现最佳...",
})
print(answer)
​

步骤 3：多模型路由——根据复杂度分派模型

不是所有问题都需要最贵的模型。一个实用的策略是根据查询复杂度动态选择模型：

import json
from openai import OpenAI

router_client = OpenAI()  # 用轻量模型做路由判断

ROUTE_PROMPT = """判断以下查询的复杂度，只输出 JSON：
{"complexity": "simple"|"medium"|"complex", "reason": "一句话理由"}

查询：{query}

复杂度定义：
- simple: 事实查询、定义、列表（如"什么是 RAG"）
- medium: 需要综合多个信息点的回答（如"RAG 和微调各有什么优缺点"）
- complex: 需要推理、比较或深入分析的开放性问题"""


class ModelRouter:
    """根据查询复杂度路由到不同 LLM。"""
    
    def __init__(self):
        self.clients = {
            "simple": OpenAI(),  # GPT-4o-mini（默认）
            "medium": OpenAI(),
            "complex": OpenAI(),
        }
        self.model_map = {
            "simple": "gpt-4o-mini",      # 最便宜最快
            "medium": "gpt-4o-mini",      # 性价比高
            "complex": "gpt-4o",          # 最强模型
        }
    
    def route(self, query: str) -> str:
        """判断查询复杂度并返回模型名。"""
        response = self.clients["simple"].chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": ROUTE_PROMPT.format(query=query)}],
            temperature=0,
            max_tokens=100,
        )
        try:
            result = json.loads(response.choices[0].message.content)
            complexity = result.get("complexity", "medium")
            return self.model_map.get(complexity, "gpt-4o-mini")
        except (json.JSONDecodeError, KeyError):
            return "gpt-4o-mini"  # 解析失败用默认模型
    
    def generate(self, query: str, contexts: list) -> str:
        """路由 + 生成一体化。"""
        model = self.route(query)
        return generate_rag_answer(query, contexts, model=model)


# 使用示例
router = ModelRouter()
print(f"简单查询路由到: {router.route('什么是向量数据库')}")      # gpt-4o-mini
print(f"复杂查询路由到: {router.route('对比分析 FAISS 和 Milvus 在不同数据规模下的性能表现')}")  # gpt-4o
​

成本节省效果：在实际企业知识库中，约 60-70% 的查询是简单/中等级别，用 GPT-4o-mini 处理。只有 30-40% 的复杂查询才路由到 GPT-4o。整体成本可以降低 50-60%，而端到端质量下降通常不超过 5%。

主流 LLM 在 RAG 任务上的实测对比

以下基于公开基准测试和实际项目经验，对比主流模型在 RAG 任务上的表现（以中文知识库问答为例）：

几个关键发现值得注意：

第一，Claude 3.5 Sonnet 在忠实度指标上表现最好，这与 Anthropic 训练时强调"忠于上下文"的策略直接相关。如果你的 RAG 应用对准确性要求极高（如医疗、法律），Claude 值得优先考虑。

第二，GPT-4o-mini 的性价比非常突出——忠实度达到 GPT-4o 的 92%，但价格只有 6%。对于大多数非极端场景，4o-mini 是首选。

第三，国产模型（Qwen2、DeepSeek）在中文 RAG 任务上已经非常接近国际一流水平，且 API 价格更低。如果知识库以中文为主，完全可以用国产模型替代 GPT 系列。

流式输出——提升用户体验的关键技术

在 Web 应用中，等待 LLM 生成完整回答可能需要 3-10 秒，用户体验很差。流式输出（Streaming）让 LLM 逐 token 返回结果，用户可以实时看到回答逐渐生成：

def generate_streaming(
    query: str, contexts: list, model: str = "gpt-4o-mini"
):
    """流式生成 RAG 回答，逐 token 输出。"""
    context_text = "\n\n".join(
        f"[文档 {i+1}]\n{ctx}" for i, ctx in enumerate(contexts)
    )
    
    stream = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "基于参考文档回答，不要编造信息。"},
            {"role": "user", "content": f"文档：\n{context_text}\n\n问题：{query}"},
        ],
        temperature=0.1,
        stream=True,  # 关键参数
    )
    
    for chunk in stream:
        if chunk.choices[0].delta.content:
            yield chunk.choices[0].delta.content


# 使用：逐 token 打印
for token in generate_streaming("什么是 RAG？", ["RAG 是检索增强生成技术..."]):
    print(token, end="", flush=True)
​

流式输出不仅改善用户体验，还能降低首字延迟（Time To First Token, TTFT）的感知。用户在 200-500ms 内就能看到第一个字开始出现，比等待 3 秒看到完整回答的体验好得多。在生产部署时，建议用 Server-Sent Events（SSE）或 WebSocket 将流式 token 推送到前端。

步骤 4：LLM 输出质量监控

集成 LLM 后，需要持续监控输出质量。以下是一个轻量级的质量监控方案：

import time
from dataclasses import dataclass, field
from typing import Optional


@dataclass
class LLMCallRecord:
    """单次 LLM 调用记录。"""
    timestamp: float
    query: str
    model: str
    response_length: int
    latency_ms: float
    input_tokens: int = 0
    output_tokens: int = 0
    error: Optional[str] = None


class LLMMonitor:
    """LLM 调用质量与成本监控器。"""
    
    def __init__(self):
        self.records: list[LLMCallRecord] = []
    
    def record_call(
        self, query: str, model: str, response: str,
        latency_ms: float, input_tokens: int = 0,
        output_tokens: int = 0, error: str = None,
    ):
        self.records.append(LLMCallRecord(
            timestamp=time.time(), query=query, model=model,
            response_length=len(response), latency_ms=latency_ms,
            input_tokens=input_tokens, output_tokens=output_tokens,
            error=error,
        ))
    
    def summary(self) -> dict:
        """输出最近的调用统计摘要。"""
        if not self.records:
            return {}
        
        recent = self.records[-100:]  # 最近 100 次调用
        latencies = [r.latency_ms for r in recent]
        errors = [r for r in recent if r.error]
        total_input = sum(r.input_tokens for r in recent)
        total_output = sum(r.output_tokens for r in recent)
        
        return {
            "total_calls": len(self.records),
            "recent_100": {
                "avg_latency_ms": sum(latencies) / len(latencies),
                "p95_latency_ms": sorted(latencies)[int(0.95 * len(latencies))],
                "error_rate": len(errors) / len(recent),
                "avg_response_length": sum(
                    r.response_length for r in recent
                ) / len(recent),
                "total_input_tokens": total_input,
                "total_output_tokens": total_output,
            },
        }
​

需要监控的核心指标：

• P95 延迟：用户体验的瓶颈指标。如果 P95 > 5 秒，用户会明显感到等待
• 错误率：API 调用失败的比例。>1% 需要排查（通常是速率限制或服务不稳定）
• Token 消耗：每天/每月的 token 消耗量，用于成本预估
• 平均回答长度：如果突然变短，可能是 LLM 截断或上下文溢出

完整示例：带监控的 RAG 生成器

class MonitoredRAGGenerator:
    """带质量监控的 RAG 生成器。"""
    
    def __init__(self, model: str = "gpt-4o-mini", temperature: float = 0.1):
        self.client = OpenAI()
        self.model = model
        self.temperature = temperature
        self.monitor = LLMMonitor()
    
    def generate(self, query: str, contexts: list, max_tokens: int = 2000) -> str:
        start = time.time()
        try:
            answer = generate_rag_answer(
                query, contexts, model=self.model,
                temperature=self.temperature, max_tokens=max_tokens,
            )
            latency = (time.time() - start) * 1000
            
            self.monitor.record_call(
                query=query, model=self.model, response=answer,
                latency_ms=latency, input_tokens=0, output_tokens=0,
            )
            return answer
        except Exception as e:
            latency = (time.time() - start) * 1000
            self.monitor.record_call(
                query=query, model=self.model, response="",
                latency_ms=latency, error=str(e),
            )
            raise
​

常见问题 FAQ

Q1：RAG 系统中 GPT-4o 和 GPT-4o-mini 的质量差距有多大？

A：在标准 RAG 基准测试（如 RAGAS 框架下的 faithfulness 和 answer_relevancy 指标）上，GPT-4o 通常比 GPT-4o-mini 高 5-15%。但在大多数实际业务场景中，这个差距用户很难感知——因为 RAG 的质量瓶颈往往在检索环节而非生成环节。建议先用 GPT-4o-mini 跑基准，如果 faithfulness >0.85 且用户满意度可接受，就没必要升级。

Q2：本地部署 LLM 做 RAG 生成可行吗？质量够吗？

A：可行，但需要选对模型。推荐 Qwen2-72B-Instruct 或 DeepSeek-V2-Chat（需 2-4 张 A100 GPU）。这两个模型在中文 RAG 任务上的表现接近 GPT-4o 水平的 85-90%。主要挑战不在质量而在运维——需要管理 GPU 资源、处理并发请求、维护模型更新。如果团队没有 GPU 运维经验，API 调用通常更划算。

Q3：如何处理 LLM 的上下文窗口不够长的问题？

A：两个策略：减少输入（更精准的检索 + 更短的重排截断）或换更大的模型。实际操作中，大多数 RAG 场景的上下文在 4000-8000 tokens（5-10 个文档片段），GPT-4o-mini 的 128K 窗口绰绰有余。只有当你需要把整篇长文档（如 50 页合同）完整送入 LLM 时，才需要考虑 200K 窗口的模型。

最佳实践与避坑

• RAG 场景用低 temperature：默认 0.1，最高不超过 0.3。高温度是 RAG 幻觉的最大帮凶之一
• 在 Prompt 中明确要求引用来源：这不仅提升用户信任，也间接提升了忠实度——LLM 在被要求引用来源时会更仔细地阅读上下文
• 设置合理的 max_tokens：根据你的业务场景设上限。客服场景 500-1000 tokens 通常够，技术文档问答可能需要 2000-3000 tokens。避免设太大导致成本浪费
• 实现优雅降级：当主力模型不可用时自动切换到备用模型。API 服务偶尔会抖动，RAG 系统不能因为单次 API 失败就整个挂掉
• 不要忽略 input token 成本：很多人只关注 output token，但 RAG 场景中 input token（检索到的上下文）通常占 70-80% 的总 token 消耗

本节小结

本节从 RAG 系统对 LLM 的特殊要求出发，建立了一个涵盖质量、速度、成本三个维度的选型决策框架。我们实现了基于 OpenAI SDK 和 LangChain 的两种标准集成方式，讲解了多模型路由策略如何在不牺牲质量的前提下降低 50% 以上的成本，并搭建了轻量级的 LLM 输出质量监控体系。

核心认知：在 RAG 系统中，LLM 的选择和配置对最终效果的影响往往被高估。检索质量才是 RAG 系统的天花板——如果检索到的文档不相关，再强的 LLM 也生成不出正确的回答。因此，在优化资源有限的情况下，优先投资检索环节（更好的嵌入模型、重排、检索策略），再考虑升级 LLM。下一节 5.2 将深入讲解提示工程在 RAG 场景中的具体实践方法。

延伸阅读

• 官方文档：OpenAI API 官方文档（模型参数详解和最佳实践指南）
• 相关论文：中国信通院发布的大语言模型能力评测报告，包含主流模型在知识问答任务上的对比数据
• 相关章节：本教程 4.3 节重排机制实现（重排后的文档质量直接影响 LLM 生成效果），5.2 节提示工程实践（优化 LLM 输出的核心技术）

关键词：RAG 知识库实战, LLM 选择, GPT-4o, Qwen, 模型配置, 多模型路由, LLM 集成, 成本优化
难度：入门到进阶
预计阅读：20 分钟