前线部署工程师 把 AI 从 Demo 变成真正能跑的业务系统

核心原理（3 分钟搞懂）

RAG 的思路极其简单：先从你的文档库找到相关段落，再把这些段落连同问题一起发给大模型。就像开卷考试——模型看着资料回答，而不是凭记忆编。

最小可运行代码（LangChain + ChromaDB）

# pip install langchain chromadb openai
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA

# 1. 加载文档
loader = PyPDFLoader("company_rules.pdf")
docs = loader.load()

# 2. 切分文档——这步最重要，后面讲为什么
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,        # 每块 500 字符
    chunk_overlap=50,      # 相邻块重叠 50 字符
    separators=["\n\n", "\n", "。", "，", " "]  # 按段落→行→句→逗号切
)
chunks = splitter.split_documents(docs)

# 3. 向量化 + 存入 ChromaDB
embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-small-zh-v1.5"  # 中文 Embedding 模型
)
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db")

# 4. 构建检索链
retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 5}  # 检索 Top 5 相关段落
)

# 5. 生成答案
llm = ChatOpenAI(model="deepseek-chat", temperature=0)
qa = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True  # 返回引用来源
)

result = qa.invoke({"query": "年假最多能请几天？"})
print(result["result"])
print("来源文档：", [doc.metadata for doc in result["source_documents"]])

分块策略实测对比：为什么 chunk_size 是 RAG 最大的坑

分块大小直接影响检索质量。以下是同一套文档、同一批问题，不同 chunk_size 的实测对比：

RAG 三个最常见的坑

Agent 到底是什么

普通对话是"你问我答"，Agent 是"你说目标，它自己拆步骤、调工具、执行任务、返回结果"。比如"帮我查上周销售额并生成报告发邮件"，Agent 会自动调用数据库查询工具→文档生成工具→邮件发送工具来完成。

Agent 的底层机制是 Function Calling：模型本身不能执行代码，但它能告诉你的程序"请调用 weather_api(city="北京")"，你的程序执行后把结果返回给模型，模型再决定下一步。

ReAct 循环图解

最小可运行代码：带工具调用的 Agent

# pip install langchain langgraph openai
from langchain_openai import ChatOpenAI
from langchain.tools import Tool
from langgraph.prebuilt import create_react_agent

# 1. 定义工具
def search_web(query: str) -> str:
    """搜索网络获取最新信息"""
    # 这里用你自己的搜索 API
    return f"搜索结果：{query} 的相关信息..."

def calculator(expression: str) -> str:
    """数学计算"""
    try:
        return str(eval(expression))
    except:
        return "计算失败"

tools = [
    Tool(name="search", func=search_web, description="搜索网络获取最新信息"),
    Tool(name="calculator", func=calculator, description="数学计算"),
]

# 2. 创建 Agent
llm = ChatOpenAI(model="deepseek-chat", temperature=0)
agent = create_react_agent(llm, tools)

# 3. 执行任务
result = agent.invoke({
    "messages": [{"role": "user", "content": "查一下北京今天的气温，然后换算成华氏度"}]
})

for msg in result["messages"]:
    print(f"[{msg.type}] {msg.content}")

Function Calling 原始请求格式（不用框架时）

# 直接调 API 的 Function Calling
import requests

response = requests.post(
    "https://api.deepseek.com/v1/chat/completions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "model": "deepseek-chat",
        "messages": [
            {"role": "user", "content": "北京今天多少度？换算成华氏度"}
        ],
        "tools": [{
            "type": "function",
            "function": {
                "name": "get_weather",
                "description": "获取指定城市天气",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "city": {"type": "string", "description": "城市名"}
                    },
                    "required": ["city"]
                }
            }
        }],
        "tool_choice": "auto"
    }
)

# 模型返回的是"请调用 get_weather(city='北京')"
# 你执行后把结果再发给模型，它再决定下一步

Agent 三个最常见的坑

为什么用 vLLM

vLLM 是目前最主流的开源大模型推理框架。它的吞吐量是原生 HuggingFace 推理的 10-20 倍，靠的是两项核心技术：Continuous Batching（连续批处理，请求不用等齐就处理）和 PagedAttention（分页注意力，像操作系统管理虚拟内存一样管理 KV Cache）。

最小启动命令

# 安装
pip install vllm

# 启动模型服务（兼容 OpenAI API 格式）
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --port 8000 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9 \
  --tensor-parallel-size 1

# 验证服务
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "你好"}],
    "temperature": 0
  }'

显存计算公式（部署前必算）

模型部署三个最常见的坑

好 Prompt 的五要素

1. 角色设定："你是一个专业的法律顾问"——给模型一个身份锚点
2. 任务描述："请根据以下材料回答用户问题"——明确要做什么
3. 约束条件："只基于提供的材料回答，不要编造"——划清边界
4. 输出格式："请以 JSON 格式输出，包含 answer 和 source 字段"——结构化输出
5. 示例（Few-shot）：给 1-3 个输入输出示例——模型最会"照葫芦画瓢"

企业级 RAG Prompt 模板（可直接用）

你是{company_name}的智能问答助手。

【你的职责】
基于以下检索到的参考材料，回答用户的问题。

【参考材料】
{retrieved_context}

【规则】
1. 只基于参考材料回答，不要使用材料以外的知识
2. 如果参考材料中没有相关信息，请回答"抱歉，我没有找到相关信息"
3. 回答时请标注来源，格式为 [来源: 文档名]
4. 如果用户的问题不清晰，请追问以明确意图

【用户问题】
{user_question}

【请回答】

结构化输出 Prompt（让模型输出 JSON）

请分析以下工单内容，输出 JSON 格式的分类结果。

工单内容：{ticket_content}

输出格式：
{
  "category": "分类名称（技术/业务/投诉/咨询）",
  "priority": "优先级（高/中/低）",
  "summary": "一句话摘要",
  "suggested_action": "建议处理方式"
}

注意：只输出 JSON，不要输出其他任何内容。

Prompt 调优三板斧

为什么要做评估

AI 系统的输出是不确定的——同一个输入，每次结果可能不同。你怎么知道它"好不好"？没有评估，你说"效果不错"就是拍脑袋。客户验收要数据，上线后要监控漂移，对比方案要客观标准——评估是 AI 系统的体检报告。

评估指标体系

LLM-as-Judge 实现代码

import json
from openai import OpenAI

client = OpenAI()

def llm_judge(question, answer, reference):
    """用大模型给另一个大模型的回答打分"""
    prompt = f"""请给以下回答打分（1-5分），评估维度：
- 准确性：回答是否正确
- 相关性：回答是否切题
- 完整性：是否遗漏关键信息

问题：{question}
标准答案：{reference}
待评回答：{answer}

请输出 JSON：
{{"accuracy": 1-5, "relevance": 1-5, "completeness": 1-5, "total": 总分, "reason": "评分理由"}}
"""
    resp = client.chat.completions.create(
        model="deepseek-chat",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
        temperature=0
    )
    return json.loads(resp.choices[0].message.content)

# 批量评估
test_cases = [
    {"q": "年假几天？", "ref": "5天", "ans": "根据规定年假为5天"},
    # ... 更多测试用例
]

scores = []
for tc in test_cases:
    result = llm_judge(tc["q"], tc["ans"], tc["ref"])
    scores.append(result["total"])
    print(f"Q: {tc['q']} | Score: {result['total']}/15 | {result['reason']}")

print(f"\n平均分: {sum(scores)/len(scores):.1f} / 15")

线上监控仪表盘该看什么

• 调用量趋势：日均调用、峰值时段——判断是否需要扩容
• 延迟分布：P50/P95/P99——P99 突然飙升说明有异常请求
• 错误率：超时、格式错误、内容安全拦截——按错误类型分类
• Token 消耗：每次调用平均 Token——突然增加可能是 Prompt 被注入
• 用户反馈：点赞/点踩比例——最直接的效果指标
• 人工介入率：AI 回答被人工修改的比例——越低越好

客户说出来的需求 80% 不是真实需求。FDE 的工作是用对的提问方式把真实痛点挖出来。以下是实战中验证有效的话术模板：

客户老板经常提不切实际的需求——"让 AI 100% 准确""用 AI 替代所有人工""一周内上线"。直接说"做不到"会丢信任，FDE 的话术是"做不到 X，但可以做到 Y"：

万能话术公式

这个公式的核心是：永远给出选项，让老板做决策。你不是说"不行"，你是说"这样行，那样也行但更贵，你选"。

Demo 演示是 FDE 的高光时刻，也是最容易翻车的时刻。以下是血泪经验：

演示前：Plan B 清单

• 网络备份：客户现场 WiFi 可能突然不行 → 准备手机热点 + 离线版 Demo
• 预录视频：万一系统完全崩了，录屏视频兜底——"这是之前跑通的完整流程"
• 预设问题：不要现场即兴提问，提前准备 10 个验证过效果的问题，演示时用这些
• 数据脱敏：确认演示数据不含敏感信息——你不知道会议室里坐着谁
• 提前到场 30 分钟：连网络、测系统、跑一遍，确保万无一失

演示中：节奏控制

• 先讲价值再讲功能："这个系统能帮你们省 60% 的工单处理时间"→ 然后才演示怎么用
• 一次只演示一个场景：不要功能铺满屏，聚焦一个完整流程走通
• 故意留一个"小瑕疵"：让客户发现一个可以改进的点 → 客户觉得"参与了设计"，比"完美但与我无关"效果好
• 看到延迟就解释：模型生成时屏幕空白 → "AI 正在从 8000 份文档中检索相关信息"，把等待变成展示