第1892篇：大模型能力的边界认知——它能做什么、不能做什么、将来能做什么

去年有个朋友找我咨询，说他们老板要求用GPT-4做一个实时股价预测系统，"既然大模型这么厉害，预测股票应该没问题吧"。我当时就感觉这事儿不好办，不是因为技术实现复杂，而是因为这个需求本身就建立在对大模型能力的误解上。

这种误解太普遍了，而且往往是双向的——要么高估到觉得大模型无所不能，要么低估到觉得大模型只是个"高级搜索"。真实情况在哪里？今天认真讲一讲。

---

一、认识大模型的本质：一个极其复杂的条件概率机器

这个说法听起来很"祛魅"，但搞清楚这一点，你才能准确理解它的能力边界。

大模型在做的事情，从数学角度看，就是在给定上下文 x₁, x₂, ..., xₙ 的条件下，预测下一个token xₙ₊₁ 的概率分布。一个Token接一个Token地生成，每步都在做这个计算。

这意味着什么？

它非常擅长"像X一样思考"这类任务。让它像一个资深Java工程师一样分析代码，它确实能做到——因为训练数据里有大量Java工程师的文字，它学会了这种思维模式的语言表达。

它不擅长真正需要精确计算的任务。问它"8347 × 9823等于多少"，直接算经常错，因为它是在"预测数字序列"，不是在真正做乘法运算。

它的"记忆"和"知识"是静态的。训练截止日期之后的事情，它不知道。它也没法自己去查资料（除非你给它工具调用能力）。

---

二、大模型真正擅长的六类任务

1. 文本理解与生成

这是大模型的核心能力，也是目前最成熟的应用场景。摘要、翻译、改写、风格转换、文档生成——这些任务大模型做得相当好，有时候比人类中等水平还要强。

2. 代码理解与生成

这个能力超出了很多人的预期。不只是写代码，还包括：解释遗留代码的逻辑、重构代码结构、发现潜在的bug、把需求描述转化为代码实现。

我自己的使用感受是，对于业务逻辑相对清晰的CRUD代码，让AI生成初稿可以节省60-70%的时间。对于算法密集型的代码，节省的时间要少一些，但辅助调试的价值很大。

3. 知识问答与信息提取

在已有文本中找信息、从非结构化文本中提取结构化数据、回答基于文档的问题——这类任务大模型表现出色，是企业RAG应用的核心价值所在。

4. 推理与分析

对于需要多步推理的问题，现代大模型（尤其是o1/o3这类推理模型）已经具备了相当强的能力。思维链（Chain of Thought）技术让模型能够"一步步想"，而不是直接蒙答案。

5. 对话与交互

这是大模型最自然的应用场景——理解上下文、保持对话连贯性、根据用户反馈调整回答。客服、教学助手、陪练类产品，都在这个维度上挖掘价值。

6. 任务规划与分解

给大模型一个复杂目标，让它规划执行步骤——这个能力在Agent场景下非常有用。虽然不总是完美，但作为一个"自动化规划器"已经够用了。

---

三、大模型做不好的事情（以及为什么）

1. 精确数值计算

根本原因说了——它是语言模型，不是计算器。遇到数学密集型任务，正确做法是配工具：让大模型生成代码，然后执行代码拿结果，而不是让大模型直接算。

// 正确做法：让模型生成计算逻辑，用代码执行
@Service
public class MathAssistantService {
    
    private final ChatClient chatClient;
    
    public String solveMathProblem(String problem) {
        // 让模型把数学问题转换成代码
        String codePrompt = """
            将以下数学问题转换为Python代码并返回可执行的代码片段。
            只返回代码，不要解释。
            问题：%s
            """.formatted(problem);
        
        String code = chatClient.prompt()
            .user(codePrompt)
            .call()
            .content();
        
        // 执行代码拿结果（实际要用沙箱）
        return executeCode(code);
    }
    
    private String executeCode(String code) {
        // 调用代码执行服务
        // 实际项目中用Docker沙箱或云函数
        return codeExecutionService.run(code);
    }
}

2. 实时信息获取

大模型的训练数据有截止日期，它不知道今天发生了什么。如果你的应用需要实时信息，必须配RAG或者搜索工具。

@Service
public class RealtimeAwareService {
    
    private final ChatClient chatClient;
    private final SearchClient searchClient;
    
    public String answerWithRealtimeInfo(String question) {
        // 先判断问题是否需要实时信息
        boolean needsRealtime = requiresRealtimeInfo(question);
        
        if (needsRealtime) {
            // 调用搜索获取最新信息
            List<SearchResult> results = searchClient.search(question);
            String freshContext = buildContext(results);
            
            return chatClient.prompt()
                .system("基于以下最新信息回答问题，信息获取时间：" + LocalDate.now())
                .user("信息：\n" + freshContext + "\n\n问题：" + question)
                .call()
                .content();
        }
        
        return chatClient.prompt()
            .user(question)
            .call()
            .content();
    }
    
    private boolean requiresRealtimeInfo(String question) {
        // 简单启发式判断，也可以用模型判断
        String[] realtimeKeywords = {"最新", "今天", "现在", "当前", "实时", "最近"};
        return Arrays.stream(realtimeKeywords)
            .anyMatch(keyword -> question.contains(keyword));
    }
}

3. 持久记忆

大模型本身是无状态的，每次对话都是"全新开始"。所谓的"记住你"，是靠在提示词里塞入历史对话记录实现的，而不是真的记忆。

这带来一个工程问题：上下文窗口有限。如果对话历史太长，要么超出context limit，要么费用暴涨。解决方案是做对话摘要、记忆压缩，或者用向量数据库存储长期记忆。

4. 可靠的事实核查

大模型会"幻觉"——自信地说出错误的事实。对于需要高准确率的场景（法律、医疗、财务），单独依赖大模型是危险的，必须配上RAG、验证机制、人工审核。

5. 确定性输出

同样的输入，大模型可能给出不同的输出。对于需要100%一致性的场景（比如规则引擎、合规检查），这是一个根本性的局限。实际项目中的处理方式是：大模型做理解和初步判断，规则引擎做最终决策。

---

四、能力边界的动态变化——最近两年发生了什么

有些"大模型做不好的事"，正在被新技术突破。我说几个具体的例子。

长上下文的突破

之前说大模型处理长文档能力有限，现在Claude 3.5 Sonnet有200K token上下文，Gemini 1.5 Pro有1M token。之前很多RAG场景，现在直接把整个文档塞进context就行了，不用复杂的检索。当然，成本和推理速度是另一回事。

推理能力的提升

OpenAI的o1系列、o3系列，以及DeepSeek-R1，这些"推理模型"通过内置的Chain of Thought，在数学、逻辑、代码这类需要多步推理的任务上有了质的飞跃。之前大模型解竞赛题通过率很低，现在o3在某些数学竞赛上已经超过了大多数人类选手。

多模态能力

GPT-4V、Claude 3、Gemini的多模态能力，让大模型能够理解图片、图表、截图。这为很多场景打开了新的大门——比如直接分析错误截图、理解设计稿、从图表里提取数据。

// 多模态调用示例
@Service 
public class MultimodalService {
    
    private final ChatClient chatClient;
    
    public String analyzeImage(String imageUrl, String question) {
        return chatClient.prompt()
            .user(userSpec -> userSpec
                .text(question)
                .media(MimeTypeUtils.IMAGE_PNG, new URL(imageUrl)))
            .call()
            .content();
    }
    
    // 分析Java代码截图，提取其中的bug
    public String analyzeCodeScreenshot(byte[] imageBytes) {
        return chatClient.prompt()
            .user(userSpec -> userSpec
                .text("这是一段Java代码的截图，请找出其中可能存在的bug和优化点")
                .media(MimeTypeUtils.IMAGE_PNG, imageBytes))
            .call()
            .content();
    }
}

工具调用（Function Calling）的成熟

工具调用让大模型从"语言生成器"变成了"任务执行器"。它可以自主决定什么时候调用什么工具，大幅扩展了能力边界。那个不能实时查股价的问题，通过搜索工具就解决了。

---

五、未来3-5年可能突破的边界

这部分有点预测性质，但基于目前的技术趋势，有几个方向是相对确定的。

更强的Agent能力

现在的Agent系统还比较脆弱，复杂任务容易偏轨或者死循环。随着模型推理能力提升和工程实践的积累，Agent执行复杂多步骤任务的可靠性会大幅提高。Computer Use（控制电脑操作）这类能力已经在早期验证阶段，后续会越来越成熟。

个性化与持久记忆

OpenAI已经在ChatGPT里引入了记忆功能，未来这会成为标配。模型真正"认识你"，了解你的偏好、习惯、历史，这会让AI助手从工具变成助理。

更可靠的推理与验证

幻觉问题是大模型的长期痛点，但各种方法——检索增强、思维链验证、多模型交叉验证——都在持续降低幻觉率。五年后的大模型，在事实准确性上会比今天好很多。

实时学习与适应

现在的大模型训练一次就定型了，未来可能会有持续学习的机制，让模型能够从用户交互中实时更新知识。这会消解"训练数据截止日期"的问题。

---

六、对工程师的实践启示

理解了能力边界，工程层面的决策就清晰多了：

每个应用场景，先问这几个问题：这个任务的哪些部分大模型擅长？哪些部分需要外部工具补足？对准确率的要求是多少？用什么机制降低幻觉风险？

想清楚这些，架构设计就不会跑偏。

---

结语

大模型能力的边界，是在持续扩展的，但不是无限的。

理解它，你能设计出更合理的系统架构；高估它，你会在错误的场景上浪费时间；低估它，你会错过很多真正有价值的应用机会。

回到开头那个"用GPT-4预测股价"的例子——不是说大模型在金融领域没用，而是"预测股价"这个具体任务，超出了大模型的能力边界。换成"分析财报文本、提取关键指标"，大模型做得相当好。同样的工具，用对了地方，价值天差地别。