LLM 全景与发展脉络：能力边界与适用边界

本文聚焦工程视角，尽量把“概念与落地”打通。 注：本文为“1 月份重点篇”，提供更完整叙述与代码片段，后续月份将逐步补充案例。

🎯 文章目标

• 从发展脉络梳理 LLM 的“能与不能”
• 澄清常见误区：长上下文、万能 Agent、评测高分即好用等
• 给出工程落地的场景边界与决策清单

📚 背景/前置

• 基本范式：预训练 → 微调/指令对齐（SFT/RLHF/DPO 等）→ 推理与调用
• 供应侧：开源（Llama、Qwen、GLM、Mistral 等）与商用（OpenAI、Google、Anthropic 等）
• 需求侧：检索问答、结构化抽取、总结改写、代码助手、Agent 工具链等

🔧 核心内容

1) 发展脉络与能力边界

• 预训练决定“知识+语言能力上限”，但对特定业务“可执行性”仍需对齐
• 指令对齐提升“遵循与格式化输出”，但不保证事实真确性
• 长上下文扩展了“输入容量”，但信息检索/定位仍非模型强项，RAG 往往更稳
• 多模态拓展能力边界（图像/语音/视频），但评估与成本更加复杂

2) 适用与不适用的边界

• 适用：
  • 非结构化文本处理（摘要、改写、归纳）、泛化性强的对话/写作
  • 需要语义理解与一定推理但容错可控的场景
• 谨慎/不适用：
  • 强一致性/强正确性（结算、财务、权限）、硬实时/极低延迟（毫秒级）
  • 有严格“可解释性/审计”要求且提示难以完全约束的流程

3) 典型工程决策清单

• 知识处理优先 RAG：把变动知识放在外部，降低模型“参数规模依赖”
• 任务分层与路由：稳态需求走模板化+小模型；难题用大模型兜底
• 输出结构化：JSON Schema/正则/类型校验，上下游可执行
• 观测与治理：埋点、日志、失败样本归档，持续回放与改进

💡 实战示例：最小可行对话/函数调用

以“天气查询”为例，演示函数调用与输出约束（Node.js，OpenAI 兼容接口）：

import OpenAI from 'openai'
const client = new OpenAI({ baseURL: process.env.OPENAI_API_BASE, apiKey: process.env.OPENAI_API_KEY })

const tools = [
  {
    type: 'function',
    function: {
      name: 'getWeather',
      description: '查询城市天气',
      parameters: {
        type: 'object',
        properties: { city: { type: 'string' } },
        required: ['city']
      }
    }
  }
]

const messages = [
  { role: 'system', content: '你是实事求是的助手，只输出事实，不编造。' },
  { role: 'user', content: '明天杭州是否会下雨？' }
]

const resp = await client.chat.completions.create({ model: 'qwen2.5-7b-instruct', messages, tools })
const call = resp.choices[0].message.tool_calls?.[0]
if (call?.function?.name === 'getWeather') {
  const args = JSON.parse(call.function.arguments)
  const real = await getWeather(args.city) // 你的真实实现
  const follow = await client.chat.completions.create({
    model: 'qwen2.5-7b-instruct',
    messages: [
      ...messages,
      resp.choices[0].message,
      { role: 'tool', name: 'getWeather', content: JSON.stringify(real) }
    ]
  })
  console.log(follow.choices[0].message.content)
}

要点：

• 工具调用让“事实获取”外置，降低幻觉/时效性问题
• 使用 system 提示设定风格与边界；输出尽量结构化

📊 对比/取舍（速查）

• 开源 vs 商用：本地可控 vs 更新快/能力强；综合看“成本+时延+可靠性”
• 长上下文 vs RAG：窗口大不等于准确率高；多数知识型场景优先 RAG
• 小模型+路由 vs 大模型一把梭：多数业务先“小而稳”，再引入大模型兜底

🧪 踩坑与经验

• “全能 Agent”幻觉：复杂任务要拆分为可观测的步骤，工具链显式编排
• 输出不稳定：用模板/JSON Schema/函数参数来约束
• 链路无观测：日志埋点、失败样本归档、Prompt/模型版本化管理

📎 参考与延伸

• RLHF/DPO 等对齐方法综述
• vLLM/TGI/LMDeploy 等推理引擎对比
• RAG 基础与评估方法

💭 总结

• LLM 的“边界”来自模型能力、知识时效性与工程可控性
• 以 RAG、路由、结构化输出、观测治理为抓手，稳步推进落地