要点一：按上下文预测
模型根据已有文本预测下一个词，逐词生成完整回答。它没有内置数据库，依据来自训练数据与当前上下文，这正是需要检索与引用来源的原因，也是幻觉难以根除的机制来源。
要点二：预训练与对齐
预训练让模型学会语言规律，对齐让它更符合指令与安全要求。企业感受到的听话程度多来自对齐与系统提示，而不是参数规模本身，因此提示设计与约束同样影响结果。
要点三：上下文窗口
窗口决定一次能读入多少内容。长文档要分段、摘要或先检索再输入；直接塞入超长文本会让关键信息被稀释，模型容易漏读条款，同时成本上升、响应变慢。
要点四：参数与成本
参数规模影响能力上限与推理成本，但并非越大越合适。任务简单时小模型延迟低、成本可控；复杂归纳与推理再考虑更大模型，选型应以评测结果决定。
要点五：部署形态
接口调用上线快、维护轻，但数据出内网；私有化部署数据可控，但需要算力与运维能力。选择取决于数据分级与长期使用强度，只看初期便利往往在合规评审时被推翻。
适用与不适用
适合谁
- 需要理解模型能力边界的技术负责人
- 正在做模型选型的企业
- 准备私有化部署评估的 IT 团队
不适合谁
- 只需采购成品应用、不涉及选型的业务部门
- 期望模型自带企业知识、无需检索的场景
典型场景
某企业的技术团队评估客服问答方案，先比较接口调用与私有化部署的数据路径，再用同一套评测集测试两个规模不同的模型，最终按知识范围与并发量确定组合方案。
可执行步骤
- 明确任务需要读入多长的上下文
- 按数据分级确定可用部署形态
- 用同一评测集比较不同规模模型
- 实测延迟、并发与长文本表现
- 锁定版本并记录评测基线
常见坑
- 把模型当知识库，不建检索，回答内容无法追溯来源。
- 为省事把整本手册塞进上下文，关键条款被忽略且成本上升。
- 只看参数规模选型，忽略延迟与并发，上线后体验下降。
- 未锁定模型版本，供应商更新后输出变化，历史评测失效。
自检与验收清单
- 是否明确上下文长度需求
- 是否按数据分级选部署形态
- 是否用统一评测集比较模型
- 是否实测延迟与并发
- 是否记录模型版本与基线
常见问题
参数量越大越好吗？
不是。参数影响能力上限，也影响成本与延迟。多数企业任务用中等规模模型加检索即可满足，关键是评测结果而不是参数数字。
模型会记住我们的数据吗？
取决于服务条款与部署方式。接口调用需确认数据是否用于训练；私有化部署数据留在本地，但仍需做好权限与日志管理。
上下文窗口越大越省钱吗？
相反，长上下文通常意味着更高消耗与更慢响应。合理做法是先检索再输入相关内容，而不是把整篇材料一次性塞入。