企业官网建设流程全解析

今日学习目标

1. 了解大模型发展的关键时间节点。

2. 深刻理解大模型“幻觉”的本质、分类、产生原因及四种主流解决方法。

3. 掌握提示词工程的五项原则，能区分system、user、assistant、tool角色。

4. 理解 RAG、微调、AI Agent 的核心思想与区别。

5. 掌握安全调用云端大模型的方法，能看懂并修改调用代码。

6. 理解大模型调用外部工具的基本思想。

一、大模型发展史：关键时间节点

1. 大模型发展的三个核心驱动力

• 数据：模型学习的“教材”，互联网海量文本是基础。

• 算法：模型学习的方法，如 Transformer 架构中的“注意力机制”。

• 算力：GPU、TPU 等硬件，让大规模训练成为可能。

2. 大模型发展的关键时间节点

4. 一句话记住发展史

AlexNet（深度学习起点）→ Transformer（注意力机制）→ GPT/BERT（预训练）→ GPT-3（提示词价值）→ ChatGPT（引爆应用）→ GPT-4/开源模型（多模态/长上下文）→ 推理模型（DeepSeek等）

二、大模型幻觉：为什么它会一本正经地胡说八道

1. 幻觉的定义

大模型的“幻觉”是指：模型生成了错误、无依据、与事实不一致，或者不符合用户要求的内容。

🧠 形象理解：模型像一个记性不好但很自信的“学渣”，考试时不会做就编答案，还编得头头是道。

2. 一个让你警惕的例子

假设你问模型：“请介绍一下《AI与未来工作》这本书的核心观点。”

模型自信地回答：“这本书由王建国教授和李晓琳博士合著，2023年由科技出版社出版。书中主张AI将在2030年前取代40%的岗位，并建议每个人都要学习编程。”

事实是：这本书根本不存在。模型把“AI”“教授合著”“科技出版社”“取代岗位”这些常见元素拼凑在了一起。

3. 幻觉的两大分类

4. 幻觉产生的三个根本原因

原因一：模型的本质是“概率接龙”，不是“知识数据库”

大模型的核心任务：给定上文，预测下一个最可能出现的词。它追求的是“语言流畅”，而不是“事实正确”。

• 比如你说“中国的首都是……”，模型大概率接“北京”，因为训练数据里最常见。

• 但如果训练数据里有错误信息（比如某个帖子说“中国的首都是上海”），模型也可能学到错误。

原因二：训练数据有局限（导致“事实性幻觉”）

• 知识过时：模型的训练数据截止于某个时间点。2023年训练的模型不知道2025年的新闻。

• 数据本身不准确：互联网上有大量谣言、错误信息、偏见。

• 知识盲区：公司内部资料、你的私人笔记，模型根本没学过。

• 数据代表性偏差：训练数据中某些事实占主导，导致模型对少数派但正确的事实认知不足。

原因三：模型被训练成“讨好型人格”（导致“忠实性幻觉”）

• 指令理解偏差：当用户指令模糊或复杂时，模型可能只执行它“认为”的核心任务，忽略其他细节。

• 上下文处理局限：即使上下文窗口很大，模型仍可能出现“中间遗忘”现象（对中间部分信息关注度下降）。

• 推理能力不足：在复杂推理任务中，模型可能在某个步骤犯微小错误，导致后续所有步骤都出错。

• 缺乏“我不知道”的概念：模型被奖励“回答了用户”而不是“回答正确”，所以遇到不会的问题宁可编也不说不知道。

三、解决幻觉的四大放法

法宝一：提示词工程 —— 把话说清楚

定义：通过设计清晰、结构化的指令，引导模型按规则回答。成本最低、见效最快。

五项原则：

进阶技巧：

• 思维链与自我验证：要求模型展示推理步骤，并检查是否存在矛盾。

  提示词示例：“请分步推理，并在给出最终答案前，检查是否存在与中间步骤矛盾的事实。”

• 提供参考与要求引用：给予参考文本，要求回答必须引用原文。

  提示词示例：“你的回答必须严格来自上述文档，如果文档中没有相关信息，请明确回答‘无法得知’。”

• 设定置信度：要求模型评估自己答案的确定性。

  提示词示例：“请回答以下问题，并以‘我对答案的置信度为：高/中/低’结尾。”

局限：提示词不能给模型灌输新知识。如果模型完全不知道某个领域，提示词也救不了。

法宝二：RAG（检索增强生成）—— 开卷考试

定义：在回答前，先从外部知识库检索相关材料，然后让模型基于材料回答。

工作流程（三步）：

1. 检索：用户提问 → 系统去知识库（向量数据库）搜索相关文档片段。

2. 增强：把这些片段与用户问题拼接，形成新的提示词。

3. 生成：模型基于这个“证据充足”的提示词生成答案。

通俗类比：

• 闭卷考试：模型只靠自己的记忆（容易编错）

• 开卷考试：模型可以翻书（基于资料回答）

为什么RAG强大？

• 知识实时更新：更新知识库即可，不用重新训练模型。

• 可溯源：模型可以告诉用户“答案来自文档第X页”。

• 解决私有知识：公司内部文档、产品手册都可以作为知识库。

• 减少事实性幻觉：模型有依据，不容易瞎编。

例子：

假设你是一个航空公司客服机器人。用户问：“我订的CA1234航班，原定今天下午3点起飞，现在状态是什么？”

• 无RAG：模型可能编“航班已取消”或给出错误信息。

• 有RAG：系统先检索实时航班数据库，查到“CA1234延误至下午5点”，然后模型回答：“根据最新航班信息，CA1234延误至下午5点。”

局限：需要搭建检索系统（如向量数据库），且如果知识库里没有相关信息，模型仍可能瞎编。

法宝三：模型微调 —— 回炉深造

定义：用特定领域的高质量数据，继续训练模型，让模型在该领域变得更专业。

通俗类比：

• 提示词是“临时交代任务”。

• 微调是“送模型去专业学校进修”。

两种微调方式对比：

例子：

一家汽车维修公司要做一个故障诊断助手。他们收集了2万条维修记录（故障现象 → 可能原因 → 建议操作），用LoRA微调一个开源模型。

• 微调前：模型可能给出通用建议“请去维修店检查”。

• 微调后：模型能说出“根据您描述的‘发动机抖动、故障灯亮’，可能是火花塞问题，建议先检查火花塞”。

微调 vs 提示词 vs RAG：

实际项目中，三者常组合使用：微调让模型懂领域，RAG提供最新资料，提示词约束输出格式。

法宝四：AI Agent —— 让模型学会“动脑子”和“用工具”

定义：Agent是一个智能体，模型作为“大脑”，能够拆解任务、选择工具、调用工具、验证结果。

为什么Agent能对抗幻觉？

• 工具使用：当模型不确定一个事实时，可以主动调用搜索引擎去查询最新信息，而不是依赖内部记忆。

• 代码解释器：对于数学或逻辑问题，模型可以编写并运行代码来获得精确结果，避免计算错误。

• 多步验证：Agent可以设计一个验证循环，先生成一个答案，再换一种方式（如搜索）去验证该答案的一致性。

Agent工作流程图：

用户目标 ↓ 模型拆解子任务（规划） ↓ 选择工具（如搜索/计算器/数据库） ↓ 程序执行工具 ← 真正执行动作的是程序，不是模型 ↓ 工具结果返回 ↓ 模型整合答案（可能还需要再次调用工具）

例子：

用户问：“帮我查一下明天杭州的天气，如果是晴天就推荐西湖，如果是雨天就推荐室内博物馆。”

普通模型可能会瞎编：“明天杭州晴天，推荐西湖。”（实际上可能下雨）

Agent的做法：

1. 规划：需要先查天气。

2. 执行：调用天气API，获取“明天杭州中雨，18-22℃”。

3. 判断：天气是雨天，所以应该推荐室内博物馆。

4. 执行：调用搜索API，搜索“杭州室内博物馆推荐”。

5. 生成：基于真实天气和搜索结果回答：“明天杭州中雨，推荐您去浙江省博物馆（室内）。”

Agent的局限：目前还不够稳定，可能出现规划错误或工具调用死循环，需要好的框架（如LangChain）和足够的测试。

四大法宝对比总结表

未来趋势：构建“微调过的专业模型 + RAG知识心脏 + Agent协作四肢”的超级个体。

四、提示词中的角色划分

当你通过API调用大模型时，你需要传递一个messages列表，里面包含多个消息对象。每个消息对象有role（角色）和content（内容）。

四种核心角色

为什么需要区分这些角色？

• system的优先级通常最高，模型会优先遵守system里的规则。

• user和assistant交替出现，形成对话历史。

• tool角色在Agent场景中使用，把外部工具执行结果传回模型。

简单解释：

system定规则，user给任务，assistant给回答，tool给工具结果。

assistant 的双重身份（难点）

• 在普通API调用中：assistant是模型实时生成的回复。

• 在few-shot示例中：你可以提前写好assistant的内容，作为标准答案示例，让模型模仿。

对比表格：

五、调用云端大模型 —— 代码实战

1. API Key：你的身份凭证（安全第一！）

API Key就像你家钥匙，绝对不能：

• 写死在代码里并上传到GitHub。

• 截图发到任何地方。

• 明文写在文档里。

正确做法：

• 存到环境变量（如OPENAI_API_KEY=xxx）。

• 代码中用os.getenv("OPENAI_API_KEY")读取。

• 修改环境变量后，重启你的编辑器（PyCharm/VSCode）。

2. messages 结构示例

[ {"role": "system", "content": "你是一个旅游规划助手，只输出中文。"}, {"role": "user", "content": "推荐三个杭州的景点"}, {"role": "assistant", "content": "西湖、灵隐寺、西溪湿地"}, {"role": "user", "content": "第二个景点怎么去？"} ]

3. 代码示例一：OpenAI 兼容方式（以阿里百炼为例）

import os from openai import OpenAI # 从环境变量读取 API Key（必须提前配置好） api_key = os.getenv("OPENAI_API_KEY") if not api_key: raise ValueError("请先配置 OPENAI_API_KEY 环境变量并重启 PyCharm") # 创建客户端，注意 base_url 指向兼容接口 client = OpenAI( api_key=api_key, base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", ) # 准备消息 messages = [ {"role": "system", "content": "你是一个简洁的助手，回答尽量控制在两句话以内。"}, {"role": "user", "content": "什么是大模型幻觉？"} ] # 调用模型 completion = client.chat.completions.create( model="qwen-plus", # 模型名称 messages=messages, ) # 取出模型回复的文本内容 reply = completion.choices[0].message.content print(reply) # 查看 token 消耗（可选，用于成本统计） print(f"本次调用消耗 tokens: {completion.usage.total_tokens}")

4. 代码示例二：DashScope 原生方式

import os import dashscope # 设置 API Key dashscope.api_key = os.getenv("DASHSCOPE_API_KEY") if not dashscope.api_key: raise ValueError("请先配置 DASHSCOPE_API_KEY 环境变量") # 调用模型 response = dashscope.Generation.call( model="qwen-plus", messages=[ {"role": "system", "content": "你是一个中文助手，回答要友好。"}, {"role": "user", "content": "解释一下 RAG 是什么"} ] ) # DashScope 返回结果中，文本内容在 output["text"] print(response.output["text"])

5. 返回值的结构（非常重要！）

很多新手print(response)发现打印出一大堆看不懂的对象。正确做法是：

OpenAI 风格返回结构：

response └── choices (列表) └── [0] (第一个候选) └── message └── content (这才是模型的文字回答！) └── finish_reason (结束原因，如 "stop") └── usage └── total_tokens (总 token 消耗，用于计费) └── prompt_tokens (输入消耗) └── completion_tokens (输出消耗)

取值路径：

• OpenAI 风格：response.choices[0].message.content

• DashScope 风格：response.output["text"]

6. 选择模型：不是越强越好

• 简单任务（分类、提取关键词）：用小模型（便宜、快）

• 复杂推理、长文总结：用大模型（贵、慢但聪明）

• 中文为主：优先选择国产模型（通义千问、文心一言、DeepSeek等），性价比高

六、调用外部工具 —— 让模型不止会说话

1. 定义

调用外部工具是指：模型判断当前任务需要什么工具（如搜索、计算、查数据库），程序负责真正执行工具，然后把结果返回给模型继续生成答案。

2. 模型 vs 工具的分工

3. 简单流程

用户：帮我查一下明天北京的天气 ↓ 模型：判断需要“天气查询工具”，输出一个特殊标记（如调用函数） ↓ 程序：识别出这个标记，实际调用天气 API，拿到“明天北京晴，18-28℃” ↓ 模型：根据这个结果生成回答：“明天北京天气晴朗，气温18到28度。”

4. 为什么需要外部工具？

大模型本身不能：

• 联网搜索（除非特殊配置）

• 查数据库

• 精确计算（可能算错）

• 调用业务系统接口

外部工具补上了这些短板。模型负责“想”，程序负责“做”。

七、今日重点与难点

重点总结

难点

1. 区分事实性幻觉和忠实性幻觉：前者是“说错事实”，后者是“没按要求做”。

2. 区分RAG和微调：RAG是临时查资料，微调是长期改变模型。

3. 理解assistant的双重身份：既可以是模型实时回答，也可以是提前写好的示例。

4. 理解为什么要取choices[0].message.content：因为返回是结构化对象，不是纯文本。

5. 理解“模型负责想，程序负责做”：模型不会真的执行动作，一切工具调用都需程序实现。

八、易错点总结

九、今日小结

今天我们覆盖了：

• 发展史：关键时间节点

• 幻觉：定义、分类（事实性/忠实性）、三大原因、四大解决方法

• 提示词工程：五项原则 + 思维链/自我验证/设定置信度等进阶技巧

• RAG：检索→增强→生成三步流程

• 微调：全参数 vs LoRA，以及“灾难性遗忘”概念

• Agent：拆解任务、调用工具、多步验证

• 角色划分：system/user/assistant/tool

• 代码调用：API Key安全、messages结构、返回值解析

• 外部工具：模型与程序的分工

一句话总结今天：

大模型不是万能的，也不是完全不可用。通过提示词、RAG、微调、Agent这套组合拳，我们可以把“不靠谱的天才”驯化成“可信赖的助手”。今天的所有知识，都是为了让你在真实项目中安全、稳定、高效地使用大模型。