--- title: "06-能力边界与破局之道" created: 2026-05-13 tags: - 博客 --- # 能力边界与破局之道 前面几篇咱们聊了大模型是什么、怎么工作、有哪些可选。这篇来谈一个同样重要的话题：**大模型不能做什么**。 很多人刚接触大模型会觉得它无所不能。用着用着就会发现，它有时候会一本正经地胡说八道，有时候简单的数学题都算错，有时候回答的内容明显过时了，有时候对你公司的产品一无所知。 这些不是 bug，是大模型的**固有局限**。了解这些局限，才能在应用开发中做出合理的架构设计，知道哪些事情可以放心交给大模型，哪些需要其他技术方案来补位。 这篇的内容对于后续学习 RAG、Agent 等技术至关重要——因为这些技术正是为了解决大模型的局限而生的。 ## 大模型擅长什么 在讨论局限之前，先快速梳理一下大模型的强项，建立一个完整的能力画像： ### 文本理解与生成 这是大模型的老本行，也是它最核心的能力： **阅读理解**：给它一篇文章，让它回答关于文章的问题，准确率很高。 **文本摘要**：把长文章压缩成要点，效果非常好。 **内容创作**：写文章、写文案、写邮件，流畅度和质量都不错。 **改写润色**：修改语病、优化表达、调整语气风格，很擅长。 **信息提取**：从非结构化文本中提取关键信息、实体、关系，效率高。 ### 代码能力 现代大模型的代码能力已经非常强： **代码生成**：根据自然语言描述生成代码，各种语言都可以。 **代码解释**：解释代码逻辑、注释代码，帮助理解他人代码。 **Bug 调试**：分析报错信息，定位问题原因，给出修复建议。 **代码重构**：优化代码结构，提升可读性和性能。 **代码补全**：根据上下文补全代码片段。 ### 语言处理 **多语言翻译**：翻译质量已经接近专业翻译水平。 **语法纠错**：发现并修正语法错误。 **语气转换**：把正式文本转成口语化，或反过来。 ### 推理与分析 **逻辑推理**：多步骤的逻辑推理，尤其是有思维链加持时。 **因果分析**：分析事件的原因和影响。 **方案比较**：对比多个选项的优劣。 ### 对话交互 **多轮对话**：保持上下文一致性，理解指代关系。 **意图识别**：理解用户真正想要什么。 **情感理解**：识别文本中的情感倾向。 但是，即使在这些擅长的领域，大模型也有一些共性的问题需要注意。 ## 四大核心局限 ### 局限一：幻觉问题（Hallucination） 最危险的局限 这是大模型最广为人知的问题，也是**最危险**的问题。大模型有时候会一本正经地**编造根本不存在的事实**。它不会坦然说"我不知道"，而是会用流畅的语言、自信的语气说出看起来很像那么回事、但完全是假的内容。 #### 真实案例：AI 写的合同 假设你让大模型帮你起草一份租房合同： ``` 用户：请帮我写一份房屋租赁合同，要符合《民法典》相关规定。 ``` 大模型可能会给你一份格式工整、条款完整的合同，里面引用的法律条文看起来也很专业： ``` 根据《中华人民共和国民法典》第七百零三条规定，租赁合同是出租人将租赁物 交付承租人使用、收益，承租人支付租金的合同。 ... 第五条 违约责任 根据《民法典》第五百八十四条的规定，当事人一方不履行合同义务或者履行 合同义务不符合约定，造成对方损失的，损失赔偿额应当相当于因违约所造成 的损失... ``` 如果你不是法律专业人士，很可能觉得这份合同很专业，直接就用了。但实际核对后可能会发现： - 某个引用的条款编号和实际内容不匹配 - 某个法律概念的表述有偏差 - 某些格式要求和当地法院的实践不符 - 遗漏了某些重要的保护性条款 等到真出了纠纷，才发现这份"专业"的合同有漏洞——这时候代价可就大了。 #### 真实案例：不存在的学术引用 学术界也有类似的问题。有人让大模型写论文综述，生成的内容中引用了大量文献： ``` [1] Johnson, M. & Smith, A. (2021). "Deep Learning Approaches for Natural Language Understanding." Nature Machine Intelligence, 3(4), 234-256. ``` 看起来格式规范、期刊正规，但去查这篇论文——根本不存在。作者名字、年份、期刊、页码，全是模型"编"出来的。 #### 为什么会有幻觉 理解幻觉的成因，需要回顾大模型的工作原理： **大模型的核心任务是"预测下一个最可能出现的词"。** 它不是在知识库里查找答案，而是根据语言模式生成"看起来合理"的内容。它不知道自己说的对不对，只知道这样说"读起来很通顺"。 具体来说： 1. **训练目标不是"正确"，而是"流畅"** 模型被训练的目标是生成语法正确、语义连贯的文本，不是生成事实正确的文本。它没有"这是真的"和"这是假的"的区分机制。 2. **没有内置的事实检验** 模型内部没有知识库，也没有能力去验证自己说的是否正确。它只是在做概率预测。 3. **宁编不缺的倾向** 大模型被训练成要给出完整、有帮助的回答。当它不确定答案时，与其说"我不知道"，它更倾向于根据相关主题的语言模式"编"一个答案。 4. **语言模式的误导** 如果训练数据中某种模式出现频繁，模型可能会在不适用的场景中也套用这个模式。 #### 幻觉的几种表现形式 | 类型 | 表现 | 示例 | | --- | --- | --- | | 事实错误 | 说出不存在的事实 | 编造历史事件、虚构人物履历 | | 引用错误 | 引用不存在的文献/法条 | 编造论文、法律条款 | | 数据错误 | 给出错误的数字 | 错误的统计数据、日期 | | 逻辑错误 | 推理过程有漏洞 | 自相矛盾的论证 | | 过度推断 | 把不确定的说成确定的 | 把可能性说成事实 | #### 应对幻觉的策略 五大应对策略 **策略 1：明确要求模型承认不确定性** 在 Prompt 中明确告诉模型： ``` 如果你不确定答案，请明确说"我不确定"或"我没有这方面的信息"，不要猜测或编造。 ``` **策略 2：要求提供来源** ``` 请回答以下问题，并为你的每个关键观点提供来源出处。如果无法提供来源，请说明这是你的推测。 ``` **策略 3：使用 RAG 技术** 把相关的参考资料通过检索系统找出来，放在 Prompt 里，让模型基于这些资料回答。这样可以大幅减少幻觉。 **策略 4：人工审核关键内容** 对于法律文件、医疗建议、财务分析等高风险内容，必须有专业人士审核。 **策略 5：交叉验证** 重要信息通过其他渠道（搜索引擎、专业数据库）验证。 ### 局限二：精确计算是短板 大模型不擅长数学计算，这个问题很多人都遇到过。 #### 经典问题：3.9 和 3.11 哪个大 这是小学生都能答对的问题： ``` 用户：3.9 和 3.11 哪个大？ 某些模型的回答：3.11 更大，因为 11 > 9。 ``` 这个回答是错的。3.9 = 3.90，是大于 3.11 的。 #### 为什么会算错 理解这个问题，需要知道模型是怎么处理数字的。 **数字被切成 Token** 大模型在处理文本时会把内容切成 Token。数字也会被切分： ``` "3.11" → ["3", ".", "11"] 或 ["3.11"] ``` 取决于分词器的实现。 模型看到的是这些 Token 的组合，而不是"3.11"这个数值本身。它不是在做数学运算，而是在做**语言模式匹配**。 **语言模式的干扰** 模型在训练数据里见过很多"版本号"的比较，比如： - "Python 3.11 比 3.9 新" - “iOS 15 比 iOS 14 更新” 这些场景中，后面的数字确实代表"更新/更大"。模型学到了这个模式，但在比较小数值时错误地套用了这个模式。 **没有真正的计算能力** 大模型内部没有计算器。当你让它算 17 × 24 时，它不是在执行乘法运算，而是在"猜测"一个看起来合理的答案。 ``` 用户：17 × 24 = ? 模型的内部过程： - 见过类似的乘法题 - 17 × 24 大约是 17 × 25 = 425，减一点 - 猜一个看起来合理的数字，比如 408 实际答案：17 × 24 = 408（碰巧对了） ``` 但稍微复杂一点的计算就容易出错： ``` 用户：17 × 24 + 89 ÷ 3 = ? 正确答案：408 + 29.67 = 437.67 模型可能回答：412（随便猜的） ``` #### 计算短板的解决方案 解决计算问题的方案 **最佳方案：让模型调用计算工具** 这就是 Function Call / Tool Use 技术的用武之地。 ``` # 定义一个计算器工具 tools = [ { "type": "function", "function": { "name": "calculate", "description": "执行数学计算", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "数学表达式，如 '17 * 24 + 89 / 3'" } } } } } ] # 模型会识别需要计算的场景，输出调用请求 # 系统执行计算，把结果返回给模型 # 模型基于正确的计算结果生成回答 ``` **代码执行环境** 让模型生成代码来计算，然后执行代码获取结果： ``` # 模型生成的代码 result = 17 * 24 + 89 / 3 print(result) # 437.6666... # 然后基于执行结果生成回答 ``` **提示模型一步步计算** 通过 CoT（思维链）让模型分步计算，可以减少错误： ``` 请一步一步计算： 第一步：17 × 24 = ? 第二步：89 ÷ 3 = ? 第三步：将两个结果相加 ``` 但这仍然不能完全避免计算错误，只是降低概率。关键计算还是要用工具。 ### 局限三：知识有边界 大模型的知识来自训练数据。训练数据没有的内容，它就不知道。 #### 时间边界：知识截止日期 每个模型都有一个**训练数据截止日期（Knowledge Cutoff）**。这个日期之后发生的事情，模型是不知道的。 **示例**： ``` 用户：2025 年的诺贝尔物理学奖得主是谁？ 如果模型的截止日期是 2024 年，它会： - 诚实地说"我的知识截止到 2024 年，不知道 2025 年的获奖者" - 或者错误地猜测一个答案（幻觉） ``` #### 范围边界：私有信息不可及 训练数据主要来自公开的互联网内容。以下信息是模型不可能知道的： **企业内部信息**： - 公司的组织架构 - 内部规章制度 - 产品技术文档 - 客户数据 **个人私有信息**： - 你的个人笔记 - 未公开的研究资料 - 私人通信内容 **付费/受限内容**： - 付费论文的全文 - 订阅制服务的内容 - 需要登录才能访问的资料 **示例**： ``` 用户：我们公司的年假政策是什么？ 模型的真实情况： - 它不知道你在哪家公司 - 你们公司的员工手册不在它的训练数据里 - 它只能给出一个通用的、基于常见做法的回答 - 这个回答可能和你们公司的实际政策完全不同 ``` #### 知识边界的解决方案 **RAG（检索增强生成）** 这是解决知识边界问题的主流方案： ``` 用户提问 ↓ 从私有知识库检索相关文档片段 ↓ 把片段 + 问题一起发给大模型 ↓ 模型基于片段生成回答 ``` 通过这种方式，模型可以回答训练数据里没有的问题。 **知识库定期更新** 对于时效性要求高的场景，定期更新知识库的内容。 **联网搜索** 对于实时信息，让模型调用搜索引擎获取最新内容。 **模型微调** 把领域知识"植入"模型，让它内化这些知识。但成本较高，且知识更新不灵活。 ### 局限四：没有实时性 大模型的知识是静态的，训练完就定格了。它不知道"现在"发生了什么。 #### 不知道的实时信息 - 今天的天气 - 现在的股价 - 刚发生的新闻 - 当前的时间 - 实时的交通状况 #### 为什么联网的大模型能回答实时问题 你可能注意到，ChatGPT 开启联网功能后，能回答这些实时问题。这是因为它在回答之前**先去搜索引擎查了一下**，把搜索结果作为参考资料塞给模型。 本质上还是 RAG 的思路，只不过检索源是互联网而不是私有知识库。 #### 解决方案 **搜索增强** 让模型调用搜索引擎 API，获取最新的网页内容： ``` def search_and_answer(query): # 1. 调用搜索引擎 search_results = search_api.search(query) # 2. 提取搜索结果摘要 context = extract_snippets(search_results) # 3. 把搜索结果和问题一起发给模型 answer = llm.generate( f"根据以下搜索结果回答问题：\n{context}\n\n问题：{query}" ) return answer ``` **API 工具调用** 让模型调用各种实时数据 API： ``` tools = [ { "name": "get_weather", "description": "获取指定城市的实时天气", "parameters": {"city": "string"} }, { "name": "get_stock_price", "description": "获取指定股票的实时价格", "parameters": {"symbol": "string"} }, { "name": "get_current_time", "description": "获取当前时间", "parameters": {} } ] ``` 这些都是 Agent 架构的重要组成部分，后续章节会详细讲解。 ## 破局技术详解 了解了局限，现在来详细看看每种破局技术的原理和使用方法。 ### 技术一：Prompt 工程 **Prompt 工程是优化大模型输出的第一道防线，零成本，立即生效。** #### 什么是 Prompt 工程 Prompt 工程是通过精心设计输入的提示词，引导模型更好地完成任务的技术。 好的 Prompt 可以： - 减少幻觉 - 提高回答的准确性 - 控制输出格式 - 引导模型的思考方式 #### 核心技巧 **技巧 1：明确角色和背景** ``` 你是一个专业的法律顾问，专注于劳动法领域，有 10 年执业经验。 你的回答应该准确、专业，同时用普通人能理解的语言表达。 ``` **技巧 2：约束回答范围** ``` 请仅基于以下提供的资料回答问题，不要添加资料中没有的信息。 如果资料中没有相关内容，请说"提供的资料中没有这方面的信息"。 ``` **技巧 3：要求承认不确定性** ``` 如果你不确定某个信息的准确性，请明确说明这是你的推测，而不是确定的事实。 对于你不知道的问题，请直接说"我不知道"，不要编造答案。 ``` **技巧 4：提供示例（Few-shot）** ``` 请按以下格式提取文本中的实体： 示例输入：苹果公司发布了iPhone 15，CEO库克出席了发布会。 示例输出： - 公司：苹果公司 - 产品：iPhone 15 - 人物：库克 现在请处理以下文本： ... ``` **技巧 5：分步引导（CoT）** ``` 请按以下步骤分析这个问题： 1. 首先，识别问题的核心是什么 2. 然后，列出解决这个问题需要的信息 3. 接着，逐步分析每个相关因素 4. 最后，给出你的结论和理由 ``` **技巧 6：限定输出格式** ``` 请以 JSON 格式返回结果，格式如下： { "answer": "你的回答", "confidence": "高/中/低", "sources": ["来源1", "来源2"] } ``` #### Prompt 工程的局限 Prompt 工程能解决很多问题，但有边界： - 无法让模型获得它不知道的知识 - 无法让模型真正进行数学计算 - 无法获取实时信息 - 复杂任务可能需要其他技术配合 ### 技术二：RAG（检索增强生成） **RAG 是解决知识边界和减少幻觉的核心技术。** #### 什么是 RAG RAG = Retrieval-Augmented Generation，检索增强生成。 核心思想：**不指望模型什么都知道，而是在需要的时候给它"喂"相关资料**。 #### RAG 的工作流程 ``` 用户提问："我们公司的年假政策是什么？" ↓ 【检索阶段】 从公司知识库中搜索"年假政策"相关的文档 ↓ 找到《员工手册》第 5 章"休假制度"相关段落 ↓ 【增强阶段】 构建 Prompt： "根据以下公司资料回答员工的问题： 【参考资料】 员工入职满一年可享受 5 天年假，每增加一年工龄增加 1 天， 上限为 15 天。年假需提前 3 个工作日申请... 【问题】 我们公司的年假政策是什么？" ↓ 【生成阶段】 大模型基于提供的资料生成回答 ↓ 回答："根据公司规定，员工入职满一年后可享受 5 天年假..." ``` #### RAG 的核心组件 **1. 文档处理** 把原始文档切成小块（chunks），便于检索和塞进上下文： ```python # 文档切分示例 def split_document(doc, chunk_size=500, overlap=50): chunks = [] start = 0 while start < len(doc): end = start + chunk_size chunk = doc[start:end] chunks.append(chunk) start = end - overlap # 重叠部分保持上下文连贯 return chunks ``` **2. 向量化（Embedding）** 把文本转换成向量，便于语义搜索： ```python from sentence_transformers import SentenceTransformer model = SentenceTransformer('BAAI/bge-base-zh') # 中文 Embedding 模型 # 把文档块转换成向量 doc_embeddings = model.encode(chunks) # 把用户问题转换成向量 query_embedding = model.encode(query) ``` **3. 向量数据库** 存储和检索向量，常用的有： - Milvus - Pinecone - Chroma - Qdrant - FAISS ``` # 使用 Chroma 示例 import chromadb client = chromadb.Client() collection = client.create_collection("company_docs") # 存储文档向量 collection.add( documents=chunks, embeddings=doc_embeddings, ids=[f"doc_{i}" for i in range(len(chunks))] ) # 检索相关文档 results = collection.query( query_embeddings=[query_embedding], n_results=5 ) ``` **4. 检索策略** 决定如何找到最相关的文档块： - **语义检索**：基于向量相似度 - **关键词检索**：基于 BM25 等传统方法 - **混合检索**：两者结合 **5. 生成回答** 把检索到的文档和问题一起发给大模型： ``` def rag_answer(query, retrieved_docs): context = "\n\n".join(retrieved_docs) prompt = f"""请根据以下参考资料回答问题。 如果资料中没有相关信息，请说明无法回答。 【参考资料】 {context} 【问题】 {query} 【回答】""" return llm.generate(prompt) ``` #### RAG 的优势 1. **解决知识边界**：可以回答训练数据里没有的问题 2. **减少幻觉**：回答基于提供的资料，而不是模型的"记忆" 3. **可追溯**：可以显示答案的来源，便于验证 4. **低成本更新**：更新知识只需更新文档库，不需要重新训练模型 #### RAG 的挑战 1. **检索质量**：检索不到相关文档，回答就没法准确 2. **上下文长度**：检索到的内容可能超过上下文窗口 3. **多跳推理**：需要综合多个文档才能回答的问题比较难处理 ### 技术三：Function Call / Tool Use **Function Call 让大模型能够调用外部工具，弥补能力短板。** #### 什么是 Function Call Function Call（函数调用）或 Tool Use（工具使用）是让大模型在需要时调用外部工具/API 的能力。 大模型本身不执行工具，它只是**判断需要调用什么工具、传什么参数**，然后由外部系统执行。 #### 工作流程 ``` 用户：北京今天天气怎么样？ ↓ 【大模型判断】 这个问题需要实时天气数据，我应该调用天气 API ↓ 【输出工具调用请求】 { "tool": "get_weather", "arguments": {"city": "北京"} } ↓ 【系统执行工具】 调用天气 API，获得结果： {"temp": 25, "weather": "晴", "humidity": 40} ↓ 【把结果返回给模型】 ↓ 【大模型生成回答】 北京今天天气晴朗，气温 25°C，湿度 40%，是个适合外出的好天气。 ``` #### 代码示例 ``` import openai # 定义可用的工具 tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的实时天气信息", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如'北京'、'上海'" } }, "required": ["city"] } } }, { "type": "function", "function": { "name": "calculate", "description": "执行数学计算", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "数学表达式，如 '17 * 24 + 89 / 3'" } }, "required": ["expression"] } } } ] # 调用模型 response = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": "北京今天天气怎么样？"}], tools=tools, tool_choice="auto" # 让模型自己决定是否调用工具 ) # 检查是否需要调用工具 if response.choices[0].message.tool_calls: tool_call = response.choices[0].message.tool_calls[0] # 执行工具（这里需要你自己实现） if tool_call.function.name == "get_weather": args = json.loads(tool_call.function.arguments) result = get_weather_api(args["city"]) # 把结果返回给模型 messages.append(response.choices[0].message) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result) }) # 模型基于工具结果生成最终回答 final_response = client.chat.completions.create( model="gpt-4", messages=messages ) ``` #### 常见工具类型 | 工具类型 | 用途 | 示例 | | --- | --- | --- | | 计算工具 | 数学计算 | 计算器、代码执行器 | | 搜索工具 | 获取信息 | 搜索引擎 API、知识库检索 | | 数据 API | 获取实时数据 | 天气、股票、汇率 | | 操作工具 | 执行动作 | 发邮件、创建日程、下单 | | 数据库 | 查询数据 | SQL 查询、图数据库查询 | ### 技术四：Agent 架构 **Agent 是把各种技术组合起来，让大模型能够自主完成复杂任务的架构。** #### 什么是 Agent Agent（智能体）是一个能够**自主感知环境、做出决策、执行行动**的系统。 在大模型语境下，Agent 通常是以大模型为"大脑"，配合各种工具和记忆系统，能够自主完成复杂任务的应用。 #### Agent 的核心能力 **1. 任务规划（Planning）** 把复杂任务分解成可执行的步骤： ``` 用户：帮我分析一下最近一周苹果股票的走势，并给出投资建议 Agent 的规划： 1. 获取苹果股票最近一周的历史数据 2. 分析价格走势（涨跌、波动） 3. 查找相关新闻和市场分析 4. 综合以上信息给出投资建议 ``` **2. 工具调用（Tool Use）** 选择合适的工具执行每个步骤： ``` 步骤 1 → 调用股票 API 获取历史数据 步骤 2 → 调用数据分析工具计算指标 步骤 3 → 调用搜索引擎获取新闻 步骤 4 → 由大模型综合分析 ``` **3. 执行和观察（Action & Observation）** 执行工具调用，观察结果，根据结果决定下一步： ``` 执行步骤 1：调用股票 API 观察结果：获得了 7 天的 OHLC 数据 判断：数据获取成功，进入步骤 2 执行步骤 2：分析数据 观察结果：周涨幅 +3.2%，波动率较低 判断：分析完成，进入步骤 3 ... ``` **4. 记忆（Memory）** 记住执行过程中的信息，便于后续步骤使用： - **短期记忆**：当前任务的上下文 - **长期记忆**：跨任务的知识积累 **5. 反思和修正（Reflection）** 如果某一步失败或结果不理想，能够调整策略重试： ``` 执行步骤 3：搜索新闻 观察结果：搜索 API 返回错误 反思：可能是关键词不够具体 修正：调整搜索关键词为 "Apple stock AAPL news this week" 重试步骤 3 ``` #### Agent 架构示意 ![[7-Blog/AI技术/大模型的介绍/assets/7f8e1f40604d7ab16de8-999f665a.svg]] #### Agent 的适用场景 - 复杂的多步骤任务 - 需要多种工具协作的场景 - 自动化工作流 - 智能助手/副驾驶 ### 技术五：模型微调（Fine-tuning） **微调是在基础模型上进行额外训练，让模型更适合特定任务。** #### 什么是微调 微调是用特定领域或任务的数据，在已经训练好的基础模型上继续训练，让模型"学会"新的知识或能力。 类比： - 基础模型 = 一个大学毕业生，有广泛的通识知识 - 微调 = 让他接受专业培训，成为某个领域的专家 #### 微调的类型 **全参数微调（Full Fine-tuning）** 对模型的所有参数都进行训练。效果最好，但成本最高。 **LoRA / QLoRA** 只训练一小部分参数（通过低秩分解），效果接近全参数微调，成本大幅降低。 **Prompt Tuning** 只训练一组可学习的提示词向量，模型参数不变。成本最低，但效果有限。 #### 什么时候需要微调 **需要微调的场景**： - 特定领域深度应用（如医疗、法律） - 需要特定的输出格式或风格 - Prompt 工程和 RAG 效果不够 - 需要内化大量领域知识 **不需要微调的场景**： - 通用对话和问答 - 知识可以通过 RAG 注入 - 没有高质量的训练数据 - 预算有限 #### 微调的成本 | 项目 | 说明 | | --- | --- | | 数据准备 | 需要高质量的训练数据，通常几千到几万条 | | 计算资源 | 需要 GPU 服务器，7B 模型约需 24GB+ 显存 | | 时间成本 | 数据准备 + 训练 + 评估，可能需要数周 | | 人力成本 | 需要有经验的工程师 | #### 微调 vs RAG 怎么选 | 维度 | RAG | 微调 | | --- | --- | --- | | 成本 | 低 | 高 | | 实施难度 | 较低 | 较高 | | 知识更新 | 灵活（更新文档即可） | 需要重新训练 | | 效果上限 | 依赖检索质量 | 可能更高 | | 适用场景 | 知识密集型问答 | 特定任务/风格 | **一般建议**：先尝试 Prompt 工程和 RAG，如果效果不满足再考虑微调。 分层应对策略 ## 实战建议：分层应对策略 面对具体项目，建议按这个优先级来应对大模型的局限： ### 第一层：Prompt 工程（零成本） 任何项目都应该首先优化 Prompt： - 写好 System Prompt，明确角色和约束 - 要求模型不确定时承认不知道 - 提供示例引导输出格式 **投入**：0 成本，几小时 ### 第二层：RAG（低成本） 如果涉及私有知识或需要引用来源： - 搭建向量数据库 - 实现检索 Pipeline - 优化检索策略 **投入**：几天开发，云服务费用 ### 第三层：Function Call（中等成本） 如果需要精确计算、实时数据、执行操作： - 设计工具集 - 实现工具调用流程 - 处理错误和边界情况 **投入**：一两周开发，API 费用 ### 第四层：Agent（较高成本） 如果任务复杂、需要多步骤自动化： - 设计 Agent 架构 - 实现规划、执行、记忆模块 - 大量测试和调优 **投入**：数周开发，持续优化 ### 第五层：微调（高成本） 只有当以上方案都不满足需求，且有充足预算和数据时： - 准备高质量训练数据 - 执行微调训练 - 评估和迭代 **投入**：数周到数月，计算资源费用 **大多数应用场景，前两三层就够了。** ## 小结 这篇咱们深入分析了大模型的四大核心局限： **1. 幻觉问题** - 会一本正经地编造事实 - 源于其"语言模式匹配"的本质 - 应对：Prompt 约束 + RAG + 人工审核 **2. 计算短板** - 不是真的在算，而是在猜 - 源于 Token 化处理和训练目标 - 应对：调用计算工具（Function Call） **3. 知识边界** - 时间边界：知识截止日期 - 范围边界：私有信息不可及 - 应对：RAG 注入知识 + 微调 **4. 实时性缺失** - 不知道"现在"发生了什么 - 应对：联网搜索 + API 工具调用 以及五大破局技术： - **Prompt 工程**：零成本优化 - **RAG**：注入私有知识 - **Function Call**：调用外部工具 - **Agent**：自主完成复杂任务 - **微调**：深度定制模型 下一篇是实战环节：搭建开发环境，从零开始调用大模型 API，把前面学的概念都给用起来。