AI 智能体的落地

存在的问题

数据脏乱差

数据是多种格式、多种版本混合的，例如 PDF、Word、Excel、HTML、关系数据库等；即使在同一种格式的数据中，也存在异常情况需要处理，例如 Excel 中的合并单元格、不同经办人员自定义的数据格式、Word 和 Excel 文档中夹杂着图片、少量的业务规则零落分散在几万字的文档中等等。数据库中有些字段因为历史遗留原因（文档缺失，人员离职等），甚至语义可能已经模糊不清。

因为模型本身是基于概率的，天然存在不确定性。如果直接将原始数据喂给模型，那么整个数据的处理过程，变成了一个黑盒，难以追溯，难以复现，也难以优化。

有限上下文

虽然模型支持百万 Token，但实际处理时，输入的信息是会被筛选或压缩的。这会导致相关内容虽然出现在提示词中，但模型有可能会忽略它。在实际的业务场景中，每一条业务规则可能都很重要，被忽略掉的信息有可能会带来要命的后果。例如原本不属于违约或侵权的场景，误判为侵权。

模糊的规则

业务规则本身可能自带模糊性，有一定的解释空间。不像代码，编译后能否运行通过是确定性的。业务规则的模糊性会导致每次跑模型出来的结果可能都不一样，这对需要审计的场景来说是难以接受的。

模糊的需求

用户常常无法描述清楚自己的业务需求，既没有 Prompt，也没有示例，并且还经常要求能够准确、快速、低成本的获得结果。

错误难以恢复

代码出错可以回退，但在实际业务运行的场景中，由于是将结果交付给客户，如果出错有可能直接变成事故，造成的损失不可恢复或者恢复的代价很大。

解决方案

数据处理

所有确定性的数据（金额、日期、合同编号、关联方等）使用确定性的方法（如正则、OCR等）进行预处理，模型只负责处理非确定性的数据（即需要依赖于人的经验进行解释的数据）。对于模糊的数据，也尽量做确定性的定义。然后在处理过程中，模型只负责在已知的几个选项中进行判断选择即可，转成确定性规则的好处是方便维护。

如果硬编码的规则无法应对所有的解析场景，那么可以考虑添加 LLM 解析进行交叉验证；

使用图结构，为数据创建结构化的索引，而不是将数据直接写入向量库。图结构能够更好的表达数据之间的结构化关系，也方便后续进行准确的查询定位，查询顺序由浅到深为：索引 -> 摘要 -> 原文片段。

规则显化

将原本模糊或者存放在经办人员脑袋中的的业务经验，用明确的逻辑和数值（可量化）显式的定义出来。这些规则在显式定义和版本化了以后，除了方便不同人员进行协商调整外，还非常方便未来的维护。当业务需求随时间出现更新时，规则只需随之更新即可。这样做还有一个额外的好处，即无形中构建了公司的知识库。新入职的人员能够基于该知识库，更好更快的上手相关业务。

分而治之

将长上下文的大任务，分解成多个短上下文的小任务，尽量命中模型的最佳上下文窗口（可能只有 8k-32lk），避免模型出现失忆。将多个小任务之间的关系，放在模型之外的 Harness 工程中进行处理，而不是让模型自行判断。

结果评估

如果缺少评估，整个 Agent 就变成了一个黑盒。当修改 Prompt 后，不知道它整体是变好了还是变差了，因此必须构建自动化的评测数据集。Agent 的每个功能，通过该测试集的评估后，能够知道它具体的性能和准确率如何。以及每次的迭代，是否影响了其他地方。简而言之，测试驱动开发。

评测可将线下的人工处理作为评估的基线，不追求完美，而是追求相对于基线的改进。例如人工出报告用时 3 小时，现在用时变成了 10 分钟。人工错误率是 20%，现在是 10%；

有些模糊地带有可能人工处理也不一定能够判断得准确，甚至两个不同的人来处理，会得出来不同的结论。针对这种情况，显然要求 Agent 100% 准确是不合理的。我们只需要让 Agent 如实回答不知道，或者如实说它没有把握，要求人工介入复核即可。而不是一本正经的胡说八道，误导用户。

考虑到市场需求在不断变化，业务规则和数据分布很可能也在跟着变化，因此评估需要定期进行，以便能够第一时间发现 Agent 的能力是否出现飘移，从而调整规则，及时迭代改进。

预期管理

模型用得越多越深，生成结果的时间越久，成本也越高。但有些场景用户可能并不需要这种深度报告式的结果，因此有必要将功能进行分层，例如分成快速模式、标准模式、思考模式，以实现耗时和精度之间的平衡。将选择权交给用户，让用户根据业务场景，调用不同的模式。在功能开始运行之前，就让用户对结果精度和耗时有了合理的预期。