二、大模型基础：什么是大模型、主流模型与能力边界

在开始使用大模型进行应用开发之前，我们首先需要建立对“大模型”这一核心对象的准确认知。大模型并非简单的“更大的神经网络”，而是基于Transformer架构、在海量数据上进行预训练、通过自监督学习获得通用语言理解与生成能力的深度神经网络模型。理解其本质、熟悉主流模型的特点、明确其能力边界，是后续进行Prompt工程、RAG（检索增强生成）或微调开发的前提。本章将系统梳理这三个核心问题，并给出工程视角下的判断框架。

上图展示了本章的知识框架。我们将围绕“核心定义”、“主流模型”和“能力边界”三个维度展开，并最终落脚到应用开发的实际选型与策略上。下面逐一深入。

2.1 什么是大模型：从参数到能力的跃迁

核心原理：规模带来的质变

大模型（Large Language Model, LLM）的核心在于“大”。这里的“大”主要体现在三个方面：参数规模大（通常指数十亿到数万亿个可学习参数）、训练数据量大（涵盖互联网公开文本、书籍、代码等多源数据）、计算资源投入大（需要数千张GPU卡训练数月）。这种规模上的扩展，使得模型在参数量超过某个阈值后，涌现出小模型不具备的“涌现能力”（Emergent Abilities），例如上下文学习（In-Context Learning）、思维链推理（Chain-of-Thought）和指令遵循能力。

从技术架构看，当前主流大模型几乎全部基于Transformer架构。其核心是自注意力机制（Self-Attention），它允许模型在处理每个词时，动态地关注输入序列中所有其他词的相关性，从而捕捉长距离依赖关系。这与传统的RNN/LSTM按顺序处理信息的方式有本质区别，也是大模型能够处理长文本、理解复杂语义的基础。

判断方法：如何识别一个模型是否为“大模型”

在实际开发中，我们通常通过以下三个指标快速判断：

1. 参数量：是否超过10亿（1B）参数。低于此量级通常被视为“预训练语言模型”而非“大模型”。
2. 上下文窗口：能否处理超过2048个的输入序列。大模型通常支持4K、8K甚至128K以上的上下文。
3. 涌现能力：是否表现出小模型不具备的少样本学习能力（Few-shot Learning）或思维链推理能力。

2.2 主流大模型概览：、LLaMA与ChatGLM

核心原理：不同家族的模型各有侧重

当前主流大模型主要分为三个技术谱系：的系列（闭源商业）、Meta的LLaMA系列（开源权重）、以及智谱AI的ChatGLM系列（开源/商用双轨）。理解它们的差异，有助于我们在开发时做出合适的选型。

• 系列（Generative Pre-trained Transformer）：作为闭源模型的代表，及后续版本在综合能力、指令遵循、多模态理解上处于领先地位。其优势在于API稳定、生态完善（函数调用、Assistants API），但数据隐私受控，且调用成本较高。
• LLaMA系列（Large Language Model Meta AI）：Meta开源的LLaMA 2/3系列，提供了从7B到70B不等的参数版本。其优势在于可本地部署、数据私有化、可深度微调。但需要较强的GPU资源，且中文能力相对弱于国内模型。
• ChatGLM系列：智谱AI推出的中英双语模型，其6B版本在消费级显卡上即可运行，中文理解与生成能力优秀，特别适合国内企业级应用。最新版ChatGLM4在工具调用和Agent能力上大幅增强。

案例拆解：选型决策的实战场景

假设我们为一家银行开发智能客服系统，要求数据不出域、支持中文、需要处理复杂的业务规则。

背景与约束：银行对数据安全要求极高，不允许调用外部API；业务场景涉及大量中文金融术语；需要模型具备一定的逻辑推理能力以处理“账户挂失”、“贷款计算”等复杂任务。

分析判断过程：

1. 首先排除系列，因为闭源API无法满足数据私有化要求。
2. 对比LLaMA和ChatGLM：LLaMA 3.1 8B虽然开源，但原生中文能力较弱，需要额外进行中文语料微调，成本较高。
3. ChatGLM4-9B在中文理解上表现优异，且支持128K上下文，可以覆盖银行的长文档（如协议条款）。
4. 最终选择ChatGLM4-9B，部署在内部GPU服务器上，并使用LoRA技术针对银行客服对话数据进行了轻量微调。

实际操作步骤：使用vLLM框架部署模型，加载ChatGLM4-9B的量化版本（INT8），将模型服务封装为兼容的API接口，供业务系统调用。

结果对比：在内部测试集上，微调后的模型对“信用卡账单查询”的意图识别准确率从82%提升至95%，且响应延迟控制在800ms以内。

复盘经验：对于中文垂直领域，优先考虑国内开源模型（ChatGLM、Qwen）可以显著降低微调成本。同时，量化部署（INT8/INT4）是平衡性能与资源的关键手段。

2.3 模型能力边界：知道“不能做什么”比“能做什么”更重要

核心原理：大模型的固有限制

尽管大模型能力强大，但存在几个不可忽视的结构性缺陷。这些缺陷并非通过Prompt工程就能完全消除，而是模型架构与训练方式决定的。

• 知识截止日期：模型的知识停留在训练数据截止时间，无法自动获取最新信息。例如，的知识截止日期是2023年10月，它不知道2024年发生的新闻。
• 幻觉（Hallucination）：模型会生成看似合理但实际错误或虚构的内容。这在涉及具体数字、引用、事实性陈述时尤为危险。
• 上下文窗口限制：虽然窗口在增大（如128K），但超出窗口后，模型会“忘记”早期内容，且对窗口中间部分的注意力容易衰减（Lost in the Middle）。
• 数学与精确计算能力弱：大模型本质是概率预测，而非精确计算器。对于多位数的乘法、复杂的逻辑推导，经常出错。
• 无法自主学习：模型在推理时不会更新自己的参数，无法从用户的反馈中实时学习。

判断方法：能力边界测试清单

在选型或开发前，建议对候选模型执行以下“边界压力测试”：

1. 事实性测试：询问“2024年巴黎奥运会开幕式日期”，观察是否胡编。
2. 数学测试：给出“123456 × 789012 = ?”，检查计算准确性。
3. 长文本测试：输入一篇5000字文章，然后询问文章开头提到的细节，测试记忆能力。
4. 指令冲突测试：给出相互矛盾的指令，观察模型是否遵循最新指令。

案例拆解：RAG如何弥补知识截止问题

场景：某法律科技公司需要开发一个“最新法规查询助手”，要求回答必须基于2024年新颁布的《公司法》修订案。

初始现象：直接使用ChatGLM4-9B，模型对“新公司法注册资本认缴期限”的回答仍基于旧法（5年内缴足），导致严重错误。

分析判断：这是典型的知识截止问题。模型训练数据未包含新法内容。

解决方案：采用RAG（检索增强生成）架构。将新公司法全文PDF切分为向量块，存入向量数据库。用户提问时，先检索相关法条，将检索结果与问题拼接为Prompt，再交给模型生成回答。

关键输入与操作：

# 伪代码示意
user_query = "新公司法下，有限责任公司注册资本认缴期限是多久？"
retrieved_docs = vector_db.search(user_query, top_k=3)
prompt = f"请根据以下法律条文回答问题：\n{retrieved_docs}\n\n问题：{user_query}"
response = chatglm.generate(prompt)

结果对比：引入RAG后，回答准确率从40%提升至98%，且回答中明确引用了“第四十七条”的具体条款。

风险与代价：RAG增加了系统复杂度（需要维护向量库），且检索质量直接影响回答质量。若检索到不相关文本，模型可能被误导。

复盘经验：当业务场景要求“事实准确”时，RAG是比微调更高效、更经济的方案。微调适合改变模型的“风格”或“能力”，而RAG适合注入“实时知识”。

2.4 常见误区与总结复盘

误区一：认为“模型越大越好”

在实际工程中，模型参数量越大，推理延迟和成本越高。对于简单的文本分类、信息抽取任务，7B-13B的模型经过微调后效果可能不输70B模型，但推理速度提升5倍以上。选型应基于任务复杂度和资源预算，而非盲目追求“大”。

误区二：忽视“上下文窗口”的实际有效长度

虽然模型宣称支持128K上下文，但实际测试中，当输入超过32K时，模型对中间部分的注意力显著下降。在开发长文档问答时，应主动对输入做分段检索，而非一次性塞入全部文本。

误区三：将“模型输出”直接作为“事实”

大模型没有“真相”概念，只有“概率”。在开发中，必须建立输出校验机制。例如，对于数字类回答，使用正则表达式校验格式；对于事实类回答，与知识库进行比对。

理解这些基础概念后，下一阶段我们将进入Prompt Engineering的学习，掌握如何高效地“指挥”大模型完成具体任务。但在此之前，请务必在本地或云端API环境中，亲自测试一下本章提到的“边界测试清单”，建立对大模型能力的直观感知。