能力边界与破局之道

前面几篇咱们聊了大模型是什么、怎么工作、有哪些可选。这篇来谈一个同样重要的话题：大模型不能做什么。

很多人刚接触大模型会觉得它无所不能。用着用着就会发现，它有时候会一本正经地胡说八道，有时候简单的数学题都算错，有时候回答的内容明显过时了，有时候对你公司的产品一无所知。

这些不是 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），便于检索和塞进上下文：

# 文档切分示例
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）

把文本转换成向量，便于语义搜索：

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 架构示意

架构示意

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，把前面学的概念都给用起来。