企业官网建设流程全解析

"我的知识库问答准确率一直上不去，是不是换个大模型就好了？"这句话，是我做大模型应用工程师这两年被问得最频繁的一句。每次听到，我都会反问对方四个问题：你的评测集是从真实日志里抽的还是自己从网上抄的？你的文档数据做过清洗和切分实验吗？上下文窗口超出之后你想过怎么办吗？你的 Agent 知道哪些事不该做吗？

这四个问题不是随口问的，它们分别对应我这两年最依赖的工程框架——EDCA OS 的四个维度：E（评测）、D（数据）、C（上下文）、A（智能体），外加一个贯穿所有环节的 OS（编排与闭环）。EDCA OS 不是一个官方标准，也不绑定任何具体厂商，它更像一套我在反复踩坑后总结出来的"大模型应用工程师必备能力模型"。

这篇文章我想结合自己从后端转岗到大模型应用方向的经历，把这个框架拆开讲清楚：它是什么、为什么大模型应用工程师必须学、以及具体怎么学。适合三种人看：准备面试大模型应用岗的求职者、已经在做 RAG 或 Agent 应用但总在 debug 的在职开发者、以及想评估团队是否要引入这类能力的团队负责人。

1. 大模型应用工程师的日常，和想象中差别很大

1.1 岗位内容三年内变化了不止一个量级

三年前有人问我大模型应用工程师是干什么的，我可以说"写提示词、调 API 参数、做个小 Demo"。现在要是还这么回答，面试官大概会觉得你在开玩笑。

我转岗前后对比过自己每天的时间分配。转岗早期，我大概有六成时间在研究怎么把提示词写得更好、怎么调 temperature 和 top_p，剩下四成时间在写胶水代码把各种接口串起来。现在完全反过来：日常工作的重点变成了搭建评测管道、清洗和构造数据、设计上下文管理策略、定义 Agent 的工具边界，真正"写提示词"的时间可能连一成都不到了。

这个变化背后有一个很现实的原因：大模型本身的推理能力一直在快速提升，模型之间的"智商差距"在缩小，但应用效果的上限却越来越取决于工程系统做得好不好。同样一个模型，有人能做出 95 分准确率的业务系统，有人只能做出 60 分的小玩具，差异不在模型的智力，而在模型外围那套工程体系。

1.2 为什么大量项目"Demo 惊艳、上线就翻车"

我见过太多项目在演示阶段效果惊艳，一上生产环境就原形毕露。这类项目通常有一个共同特征：开发团队把全部筹码押在了"模型够聪明"上，没有为真实场景里那些脏、乱、长尾的问题做准备。

举个最常见的例子：团队做企业知识库问答，找了几十个典型问题测一遍，觉得回答得真不错，准确率"目测 95%"。结果一上线，真实用户的问题五花八门——口语化表达、错别字、指代不清、多轮追问、文档里根本没有答案……原先那几十个问题只是幸存者偏差。真实日志里随便抽一百条，可能有一半是当初没见过的问法。

这其实就是 EDCA OS 里 E 和 D 两个维度缺失的典型症状：没有从真实分布里抽样构建评测集，没有对知识文档做系统化的清洗和切分，却指望模型自己"悟"出答案。

2. EDCA OS 到底是什么：拆开是四个能力，合起来是一套系统

2.1 E（评测）和 D（数据）：最不性感、却最决定成败的两层

先讲 E，评测。很多开发者的评测方式还停留在"我肉眼看看回答得好不好"。短期用没问题，但一旦系统进入迭代期，你改了一版 prompt、换了一个检索策略、调整了切分窗口，到底变好了还是变坏了？没有一套固定的评测集和量化指标，你根本说不出来，只能凭感觉。

一套基础评测体系包含三样东西：一个从真实请求里抽样并人工标注的黄金集、一组能量化的指标（比如检索召回率、答案相关度、忠实度）、一条每次改动后自动跑一遍的回归流程。有了这三样，你才敢放心迭代，否则每一次调整都是开盲盒。

再说 D，数据。大模型应用里说的数据，不只是"喂给模型训练的数据"，更多时候是"喂给检索系统的知识文档"。我复盘过不少效果差的项目，根因不是模型不行，而是文档数据压根没被处理过：PDF 解析出来是一段段乱码、表格变成了鬼画符、一个概念被拆散在两个章节里、重复内容让检索结果同质化。

2.2 C（上下文）和 A（智能体）：决定应用上限的两层

C，上下文，是大模型应用特有的工程问题。模型窗口越做越大，很多人觉得上下文不再是瓶颈，这是这两年最大的误解。窗口大不代表你能把所有东西都塞进去：token 越多，单次调用的延迟和成本涨得越快，而且大量无关信息混进窗口里，回答质量反而会下降。

真正该管理的是"上下文预算"——每个请求最多花多少 token、哪些信息必须放、哪些信息可以省略、超出预算后怎么压缩。这和给项目做成本预算是同一个思维，只是对象换成了 token。

A，智能体，则是把大模型从"问答工具"变成"执行主体"的那一层。Agent 能调用工具、能自主规划、能多轮迭代，但自由的另一面是失控风险。我给团队定的原则是：Agent 的边界必须比能力先定义好。它在什么条件下可以调用某个工具、最多迭代几步、出现冲突时听谁的、哪些操作必须人工确认，这些都属于智能体层要解决的问题。

2.3 OS 不是操作系统，而是"编排与闭环"

EDCA OS 里最后这个 OS 是整篇文章里最容易被人误解的部分。我说的 OS 不是 Windows、Linux 那种操作系统，而是 Orchestration System，编排系统。

E、D、C、A 四个能力如果是四颗独立的珠子，OS 就是把它们串成项链的那根线。具体来说，它包含三层含义：一是把评测、数据、上下文、智能体串成一条可复用的处理流水线；二是给整套系统加上可观测性，请求日志、token 消耗、工具调用记录、失败样本都要能回溯；三是建立生产环境到评测集的反馈闭环——上线后发现的失败案例，要回流进黄金集，成为下一轮迭代的回归用例。

有个伤心的现实：很多团队的 EDCA 四层单独看都有点东西，但缺了 OS 把它们串起来，结果就是每次迭代都要手动重新做一遍所有事，效率极低，而且出了问题根本不知道是哪一层先崩的。

3. 一次真实项目的复盘：EDCA 四层是怎么把项目一步步拖垮的

3.1 项目背景与最初的乐观预估

去年我参与了一个智能客服知识库项目，需求是给某零售企业的客服人员做问答辅助。数据是两千多份文档，大部分是 PDF 和 Excel，内容包括商品手册、售后政策、物流规则，加起来大概三万多页。当时团队觉得这事儿不难：模型那么聪明，文档招进去，再写个检索问答，基本就能交付了。

我提醒过先去抽真实客服问题、先做数据体检，但项目经理觉得时间紧，先跑通再说。于是我们直接搭了一版最小系统：把 PDF 用现成工具转成文本，暴力切成长度固定的 chunk，塞进向量库，检索 TopK 之后拼进 prompt。

结果自然是 demo 阶段一切顺利——因为演示用的那二十多个问题都是我们自己挑的，全是文档里写得很清楚的常规问题。

3.2 缺少 E 和 D：在"假测试集"上自嗨

上线两周后，我们拉了真实日志做分析，发现线上回答的准确率远低于演示时的 95%，真实数字大概只有六成左右。把失败样本分类之后，问题非常集中：

第一类是文档解析污染。Excel 表格转成文本后行列关系全丢了，模型把"包邮门槛 99 元"和"退货时效 7 天"这种单元格信息串在一起理解，答案自然错。第二类是切分粒度不对，政策类文档动辄几十页，固定按 500 字切，很容易把一个完整的条款拦腰截断，检索召回的是半截信息。第三类是真实问法和文档表述差异太大，客服习惯问"邮费谁出"，文档里写的是"运费承担方"，语义检索的分数根本拉不齐。

这些问题如果在 EDCA 的 D 层提前做数据体检，几天就能暴露出来；如果 E 层一开始就用真实日志构建评测集，在上线前就会现出原形。但我们当时两样都没做，等于在假测试集上自嗨了两周。

3.3 缺 C：上下文一长，模型就开始"失忆"

第一轮整改中我们优化了文档解析和切分，检索准确率上来了，但紧接着踩了第二个坑：上下文长度失控。

当时的方案是检索 TopK=6，每段几百字，再拼接用户问题、历史对话、系统指令，一次请求的输入动辄四五千 token。看起来在窗口范围内，但我们在压测时发现两个问题：一是响应延迟从 1 秒涨到 3 秒多，客服那边根本等不起；二是当检索回来的多个片段之间存在冗余甚至矛盾的信息时，模型回答反而开始"精神分裂"，一会儿按 A 条款说，一会儿按 B 条款说。

后来我把上下文当成预算来管：给系统指令、对话历史、检索文档各划一个 token 预算，加起来封顶。检索片段先做重排，只保留最相关的两条，宁可少给信息也不给垃圾信息。改动之后延迟回到 1 秒左右，回答一致性也明显改善。这里最值钱的教训是：上下文不是"能不能放下"的问题，而是"放什么、放多少、按什么优先级放"的问题。

3.4 缺 A：工具能调，但不该调的时候也在调

再往后我们给系统加了几个工具——查库存、查物流、查订单状态。这本来是想让客服直接拿到实时数据，结果 Agent 的"自由度"给我们上了一课。

因为工具调用没有做边界约束，Agent 经常干出一些让人哭笑不得的事：用户只是随口问一句"这个商品是不是停产了"，Agent 先把库存查了一遍，又去订单系统里翻历史记录，白白浪费了三四次调用，回答还慢；更严重的是有一次用户问的是售后政策，Agent 居然真的去调用了"创建退货单"的工具——虽然在沙箱环境里没造成实际损失，但这个场景把我们吓出一身冷汗。

整改方案是做三层约束：工具调用条件前置，先判断意图再决定能不能调；单轮任务最多迭代三次，超过就直接转人工；涉及创建、修改、删减这类写操作，一律走人工确认。改完之后，工具调用次数下降了七成，系统行为终于变得"可预测"了。

3.5 复盘结论：四层是乘法关系，不是加法关系

这个项目最终做完，效果大概是从六成提升到了九成以上。但支撑这个结果的不是某一个惊艳的技术突破，而是 E、D、C、A 每一层都做了大量不性感的工作。

我自己复盘时最深的感受是：这四层对最终效果是乘法关系，不是加法关系。E 是零，你根本不知道改得对不对；D 是零，模型吃进去的就是垃圾；C 是零，窗口塞再多信息也没用；A 是零，系统连最基本的边界都守不住。任何一层归零，整体效果就归零，其他层做得再好也救不回来。这也是为什么我特别强调系统化，而不是单点技术。

4. 系统化学习 EDCA OS 的实操路径：照着做就能少走弯路

4.1 第一步：用一个星期建立"评测集"，做最不性感的基建

想学 EDCA OS，我建议不要从理论开始，而是从建立评测集开始。这件事看起来很枯燥，却是一切后续工作的地基。

具体做法是：先拉你手上系统（或者一个你觉得值得做的场景）的历史日志，如果还没有日志，就去收集目标用户真实可能问的问题；然后按意图聚类，比如"退换货类""物流类""价格类"各占多少比例；接着按比例抽两三百条，人工写好标准答案，标出对应文档来源。

这个黄金集建好之后，你要选的指标可以很简单：检索命中率、答案忠实度（是否忠于给定文档）、任务完成率。不需要一上来就搞多花哨的 LLM-as-Judge，一条条人工标注两三百条，花不了多少时间，但收获远比想象大。

我在多个团队里推广过这套做法，几乎每个团队建完黄金集后都会发现同一个现象：原来以为自己系统准确率 90%，一测发现只有 70%。这才是真实水平，也是后续所有改进的起点。

4.2 第二步：把数据工程当作头等大事来做

评测集建好之后，下一步通常不是调 prompt，而是回头做数据。这里我建议按顺序做四件事：

先做解析质量体检。PDF、Excel、扫描件在转文本时经常丢信息，尤其是表格。你需要抽查转换结果，发现结构性信息丢失就必须换工具或做专门处理，这一步省不了。再做切分实验。不要固定地用"500 字一段"，而是按文档结构切，段落、章节、表格各自成块。同样的检索链路，不同切分方式下检索命中率可能差十几个百分点，值得认真跑几组对比。然后补元数据。给每个 chunk 打上来源、章节、时间、适用范围这类标签，检索时能做过滤，比如只搜某一年之后的政策。最后做去重和版本管理，文档更新后旧版本要能下线，避免新旧内容混在一起误导模型。

这套流程做完，检索系统的效果通常会上一个台阶，而你可能连 prompt 都没改过。

4.3 第三步：把 token 当预算来管理

上下文管理这件事，我建议用"预算"思维来学。你可以先给自己出一道算术题：假设每个请求分配 2000 token 输入，一天 10 万次请求，一个月按 30 天算，光输入 token 就是 60 亿。商用大模型按输入每百万 token 收费计算，这是一笔不小的开销，而且延迟也会随上下文长度明显增加。

所以上下文管理的第一原则是：给每个环节分配固定预算，谁也别超。我的默认分配方案给系统指令留 200 token，对话历史留 500 token，检索文档留 800 token，剩下的给用户问题和中间结果。超预算时按优先级压缩：历史对话可以做摘要、检索文档只保留重排后最高分的两条、多余的格式说明全部删掉。

第二原则是引入重排。检索召回 TopK 之后，用重排模型或者至少用规则按相关度重新排序，只把最高分的片段拼进上下文。很多人觉得检索出来就是最终结果，其实检索器擅长"找候选"，不擅长"挑最优"，重排这一步能显著提升回答质量。

4.4 第四步：Agent 设计从"约束"开始，而不是从"自由"开始

学 Agent 层最容易踩的坑，是把 Agent 当成"什么都能干"的万能助手。我的建议恰好相反：先定义它不能干什么。

给 Agent 做约束，我通常按三个层次落地：工具契约层——每个工具都要写明触发条件、参数格式、返回结构，Agent 只有在条件匹配时才能调用；流程控制层——设置最大迭代次数、超时时间、重试策略，避免 Agent 在失败循环里打转；权限管理层——把工具分为只读和写操作两类，写操作一律要求人工确认。

还有一个很重要的实践：给 Agent 建立失败日志。每次它调用工具出错、回答问题被用户纠正、或者超时中断，都要记录下来。积累了足够的失败样本后，你会发现大多数问题都集中在少数几个模式上，比如"意图判断错误导致工具调用错""多轮迭代跑偏到无关任务"。

5. 最后说几句大实话

如果你准备面试大模型应用工程师，或者已经在这个岗位却总觉得哪里不对劲，我的建议是别再把时间花在追新模型、追花哨框架上了。新模型的能力代差确实存在，但对绝大多数业务场景来说，换模型带来的提升远不如把 E、D、C、A 四层补全来得实在。

我见过太多简历写着"精通大模型应用"的人，问起评测集怎么建的、数据怎么清洗的、上下文预算怎么算的、Agent 边界怎么定的，一个都答不上来。这个岗位的未来，拼的不是谁会喊"大模型真厉害"，而是谁能把模型之外那套系统工程做得足够扎实。EDCA OS 不是灵丹妙药，它只是把大模型应用里那些最容易偷懒、也最容易翻车的环节摆到了台面上，逼着你一个一个去面对。

我自己现在带新项目，第一周必做两件事：拉一批真实数据建评测集，给所有文档做一遍数据体检。做完这两件事，项目能不能做、难在哪、要补什么，基本上心里就有数了。这个习惯帮我避开过无数次"demo 惊艳、上线翻车"的尴尬，也希望你能用得上。