大模型落地实践 · 菠萝吹雪 Studio

大语言模型（LLM）从 2023 年的「惊艳演示」走到 2026 年的「生产系统」，中间隔着一道巨大的工程鸿沟。本文基于实际项目经验，梳理 RAG（检索增强生成）、Agent 架构以及从 Demo 到产品的关键决策点。

RAG：让模型「有据可查」

纯 LLM 回答专业领域问题时容易产生幻觉。RAG 的核心思路是：先将用户问题向量化，从知识库中检索相关文档片段，再将片段作为上下文注入 Prompt，让模型基于真实数据生成回答。

一个生产级 RAG 流水线的关键环节：

文档解析：PDF、Word、HTML 统一转为纯文本，保留标题层级
分块策略：按语义段落切分（非固定字符数），chunk size 通常 512–1024 token，overlap 10–20%
向量化：使用 embedding 模型（如 text-embedding-3-large）生成稠密向量
检索：向量数据库（Pinecone、Qdrant、pgvector）做 ANN 搜索，结合 BM25 做混合检索
重排序：用 cross-encoder 对 top-K 结果精排，提升相关性

# 简化的 RAG 查询流程
query_embedding = embed(user_question)
candidates = vector_db.search(query_embedding, top_k=20)
reranked = cross_encoder.rerank(user_question, candidates, top_k=5)
context = "\n\n".join([doc.text for doc in reranked])
answer = llm.generate(system_prompt + context + user_question)

Agent：从问答到行动

当任务需要多步推理、调用外部工具（查数据库、发邮件、调 API）时，简单的 RAG 不够用，需要 Agent 架构。Agent 的本质是一个循环：

感知 → 思考 → 行动 → 观察结果 → 再思考 → …直到任务完成

工程实践中需要注意：

工具定义要精确：每个工具的输入输出 schema 用 JSON Schema 描述，减少模型调用错误
设置步数上限：防止 Agent 陷入无限循环，通常 10–20 步为合理上限
人工确认节点：涉及写操作（删数据、发邮件）时，强制人工审批
状态持久化：长任务需要 checkpoint，支持中断恢复

成本与延迟：不可回避的现实

GPT-4 级别模型的 API 调用成本约为每百万 token 数美元。一个复杂的 Agent 任务可能消耗 10 万 token 以上。优化策略：

简单意图用轻量模型（Haiku、GPT-4o-mini）做路由分类
缓存高频问题的 embedding 和回答
Prompt 压缩：用 LLMLingua 等工具压缩上下文，减少 50% token
批处理非实时任务，利用 Batch API 折扣

幻觉缓解：多层防御

即使有了 RAG，模型仍可能「编造」检索结果中不存在的信息。缓解手段：

引用溯源：要求模型在回答中标注信息来源段落
置信度阈值：检索结果相似度低于阈值时，回复「未找到相关信息」而非强行回答
事实核查层：用第二个模型专门检查回答是否与检索内容一致
用户反馈闭环：👍👎 按钮收集 bad case，定期更新知识库和 Prompt

从 Demo 到产品：工程化清单

一个能上线的 LLM 应用，除了模型能力，还需要：

限流与鉴权（防止 API 滥用）
对话历史存储与隐私合规
全链路日志（input → retrieval → generation → output）
A/B 测试框架（对比不同 Prompt / 模型版本）
降级策略（模型 API 超时时的 fallback 回复）

小结

大模型落地的核心不是「选哪个模型」，而是构建可靠的数据管道、控制成本边界、设计容错机制。RAG 解决「知识从哪来」，Agent 解决「任务怎么做」，工程化解决「怎么稳定运行」。三者缺一不可。