给开发者的大模型应用入门：从 Prompt 到 RAG

前言

"会调 LLM API"正在成为像"会写 SQL"一样的基础技能。本文不讲炼丹，只讲开发者视角下，构建一个可靠的大模型应用需要掌握的核心概念与工程方法。

一、先把 API 调用写对

一切从一个 Chat Completion 调用开始：

from openai import OpenAI

client = OpenAI()  # 从环境变量读取 API Key

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "你是公司客服助手，只回答售后相关问题。"},
        {"role": "user", "content": "订单怎么退款？"},
    ],
    temperature=0.2,   # 事实型任务调低，创作型任务调高
    max_tokens=500,
)
print(resp.choices[0].message.content)

两个关键参数：

• temperature：控制随机性。客服、抽取、分类等任务设 0~0.3；文案、头脑风暴可设 0.7+。
• system prompt：定义角色、能力边界和输出格式，是可控性最强的杠杆。

二、Prompt Engineering 的工程化写法

把 Prompt 当代码管理，而不是聊天记录。一个可靠的 Prompt 结构：

[角色] 你是一名资深代码审查助手。

[任务] 审查用户提交的 diff，指出 bug、安全问题、可读性问题。

[约束]
1. 只针对 diff 中出现的代码，不要臆测上下文。
2. 每条问题标注严重级别：P0(必须修) / P1(建议修) / P2(可选)。
3. 不确定时明确说"信息不足"，不要编造。

[输出格式] JSON，字段：issues[{level, file, line, description}]

三条原则：

1. 给格式约束：要求结构化输出（JSON），下游才好解析。
2. 允许说"不知道"：明确允许拒答，幻觉会显著减少。
3. Few-shot 示例：给 2~3 个输入输出示例，比十句描述更有效。

三、Function Calling：让模型调用你的代码

LLM 本身不能查数据库、发邮件。Function Calling 的模式是：模型输出"我想调用某个函数 + 参数"，由你的代码真正执行，再把结果喂回去：

tools = [{
    "type": "function",
    "function": {
        "name": "query_order",
        "description": "根据订单号查询订单状态",
        "parameters": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"],
        },
    },
}]

# 第一轮：把 tools 传给模型，若它决定调用，返回 tool_calls
# 第二轮：你执行函数，把结果以 role=tool 消息追加，再次请求

这是所有 Agent 应用的基石：模型负责决策，代码负责执行。

四、RAG：解决"模型不知道我们公司的事"

模型的知识有截止日期，更不包含你的私有数据。RAG（检索增强生成）的流程：

文档 → 切片(Chunking) → 向量化(Embedding) → 存入向量库
                                              ↓
用户提问 → 问题向量化 → 相似度检索 Top-K → 拼进 Prompt → 生成回答

实践要点：

• 切片策略比向量模型更影响效果：按语义边界切（标题、段落），块大小 300~800 token，块间保留 10%~15% 重叠。
• 检索不是只靠向量：混合检索（向量 + 关键词 BM25）通常明显更稳。
• Prompt 中注明来源：要求模型"只依据以下资料回答，并标注引用编号"，能压住大部分幻觉。
• 建立评测集：准备 50~100 条真实问答对，每次改切片/模型后跑一遍回归——没有评测的 RAG 调优是玄学。

五、工程化的必答题

把 demo 变成产品，绕不开这几件事：

1. 流式输出：用 SSE 流式返回，首字延迟从数秒降到几百毫秒，体验天差地别。
2. 成本控制：Prompt 是按 token 计费的，历史对话要做截断/摘要，避免上下文无限膨胀。
3. 超时与重试：LLM 服务有抖动，设置合理超时，失败降级到预设话术。
4. 观测：记录每次调用的 prompt、response、耗时、token 数。排查"模型答错了"没有日志寸步难行。
5. 护栏：用户输入先过敏感内容检测；模型输出如果会触发真实操作（发邮件、退款），必须有人工确认或规则校验。

总结

大模型应用开发的进阶路线很清晰：

调通 API → 写好 Prompt → Function Calling 接入现实 → RAG 接入私有知识 → 工程化保证可靠。

不要一开始就追 Agent 框架。先把单次调用的输入输出、成本、评测打磨扎实，框架只是后面顺手的一层胶水。