第 6 章 AI 技术够用课：从模型到可运行系统
6.1 FDE 需要懂技术，但不必追逐每个名词
企业不会因为方案使用了最新模型而买单，也不会因为架构图上出现很多组件就长期使用。FDE 学技术的目标，是能判断什么能力适合当前问题，知道它会在哪里失败，并把它放进可维护的系统。
大模型可以理解和生成语言，但它不是数据库，不会天然知道企业最新信息；它可以调用工具，但不会自动获得正确权限；它能规划步骤，却仍可能误解目标或编造结果。真正的应用，是模型与数据、规则、软件和人工共同组成的系统。
6.2 几个必须理解的概念
Token 是模型处理文本的基本单位。输入和输出都消耗 Token，因此长文档会影响成本和响应速度，也可能超过模型一次能够处理的范围。
上下文 是本次调用中模型能够看到的信息，包括指令、对话、文档片段和工具结果。模型能处理很长的上下文，不代表把所有资料一次塞进去就是好方案。信息越多，噪声、冲突和成本也可能越高。
Embedding 把文本、图像等内容转换为便于计算相似度的向量。它适合帮助系统找到语义相关内容，但“相似”不等于“正确”，更不等于“有权限查看”。
RAG 通常先从外部知识中检索相关内容，再让模型基于这些内容生成答案。它能让应用使用企业私有或最新知识，但效果依赖文档质量、切分、检索、排序、权限和引用机制。
Agent 是让模型围绕目标选择步骤、调用工具并根据结果继续行动的系统。它适合处理路径有变化的任务，但自主性越高，错误传播和失控风险也越大。
多模态 指模型同时处理文字、图片、语音或视频等信息。在质检、票据、设备巡检和客服录音等场景中很有价值，但仍要关注识别误差、隐私和数据体量。
理解这些概念的标准不是能背定义，而是能说清它解决什么问题、需要什么输入、会怎样失败。
6.3 提示词、知识库、工作流和工具调用
这几种能力经常同时出现，却承担不同职责。
提示词规定模型扮演什么角色、完成什么任务、遵守哪些边界以及采用什么输出格式。它能改善行为，却不能弥补缺失的数据，也不能替代真正的权限控制。
知识库让系统获得模型训练之外的信息，适合产品资料、制度、案例和操作手册等内容。知识库不是文件仓库，必须管理来源、版本、生效时间和访问权限。
工作流把任务拆成明确步骤，例如读取工单、判断类型、检索资料、生成草稿、等待确认、写回系统。步骤稳定、规则清楚时，工作流比让 Agent 自由规划更可靠。
工具调用让模型查询数据库、调用 API、发送通知或操作业务系统。MCP 等协议可以降低工具接入成本，但不能代替身份认证、权限校验、审计和错误恢复。
通常先用确定性软件控制流程和边界，再把需要语言理解与生成的部分交给模型，系统会更稳。
6.4 什么时候需要 Agent
Agent 适合步骤无法完全预先确定、需要根据中间结果选择工具的任务。例如研究人员根据用户问题在多个数据源间检索，或者运维助手根据告警信息选择不同排查路径。
如果任务步骤固定，使用普通工作流往往更合适。报销单先识别字段、再校验规则、最后进入人工审批，没有必要让模型自由决定流程。确定性越强，越容易测试、审计和维护。
判断是否需要 Agent，可以问三个问题：路径是否真的会变化？模型作错选择的代价是否可控？每一步能否被观察、限制和撤销？如果答案不清楚，先从工作流和人工确认开始。
6.5 RAG 的难点在模型之外
企业知识应用常见的问题不是模型不会回答，而是系统拿错了资料。
文档导入前要清理重复内容、区分版本并识别敏感信息；切分时要保留语义完整性和必要元数据；检索时要处理专业词、缩写和过滤条件；生成时应尽量给出来源；展示前还要检查当前用户是否有权看到相关片段。
权限过滤必须发生在可靠的软件层。不能把“请不要泄露其他部门资料”写进提示词后，就认为访问控制已经完成。
答案错误时，也不能只改提示词。先判断是原始知识错误、检索没有找到、排序不佳、上下文冲突，还是模型错误理解。不同原因需要不同修复方式。
6.6 模型选择是多目标取舍
模型效果很重要，但不是唯一标准。FDE 还要考虑响应速度、调用成本、并发限制、上下文长度、工具调用能力、部署方式、数据政策和供应稳定性。
复杂任务可以使用能力更强的模型，简单分类和格式化则可能使用更快、更便宜的模型。高风险场景不能只看平均准确率，还要关注最坏失败和拒答表现。
合理的选择方式，是用真实任务样本比较候选模型，并在效果、延迟、成本和风险之间做权衡，而不是根据排行榜直接决定。
系统也不应过度依赖单一模型的特殊行为。接口层、提示词、评测集和业务逻辑适当分离，未来切换模型才不会等同于重写项目。
6.7 面对没有理想接口的旧系统
企业现场经常遇到不能开放 API、只能内网访问或由多年旧代码维持的系统。FDE 需要在理想架构和现实之间做选择。
可以先采用只读接入，降低修改业务数据的风险；可以让 AI 生成建议，由人确认后手工写回；也可以在规则明确时使用已有导入导出机制或受控自动化。
但不是所有系统都值得强行接入。如果接口不稳定、维护责任不明，自动化带来的收益又很小，暂时保留人工步骤可能更合理。半自动不是失败，而是风险与价值之间的工程决策。
6.8 原型与生产系统的分界
原型用于验证假设，可以接受少量样本、人工准备数据和临时界面。生产系统则要面对真实用户、持续数据、权限、并发和故障。
从原型走向生产，至少要补齐身份认证、权限控制、日志审计、异常处理、超时重试、成本监控、版本管理、评测回归、数据备份和人工兜底。还要明确谁维护、故障找谁、模型或知识更新怎样发布。
判断是否进入生产，不是看界面是否完成，而是看系统失败时组织是否仍能安全工作。
本章小结
FDE 不需要追逐所有新框架，但必须理解模型、上下文、RAG、工作流、Agent 和工具调用各自的边界。稳定的企业应用通常是模型、确定性软件、可靠数据和人工判断的组合。
技术选型完成后，还要回答一个更难的问题：怎样证明系统真的有效，而不是只在几次演示中表现不错。