2.8 KiB
场景细分
第一个要思考的事情是：构建的业务场景能不能进行细分。拆分成不同的场景，每个场景只关注一个最小的业务。 目标是把所有的数据放到向量库中，然后通过向量检索全库搜索所有数据，给用户最详细的回答，让搜索没有盲区，搜什么都有。 显然这个应用是失败的，因为不可能将TB级别的数据通过向量检索就完全解决了，有太多语义上相似的chunck但是不相关的chunck出现，后来我们增加了很复杂的意图识别通过数据类别进行分类。这些一切都行不通。 你需要将你的应用按照场景细分，而不是数据细分。 比如，对于同样都是医学类数据，科研人员和药店柜员要求的准确程与深度是截然不同的。 构建智能体也是一样的，不是把所有可能会用到的工具都扔给智能体（ReAct）就可以搞定的 要思考：你构建的是什么场景？目标人群是谁？
流程拆分
场景细分之后，要考虑：流程是否可以拆分。不要完全让智能体帮你判断流程走向。
做过一个场景应用：患者过来问诊，智能体先收集患者的信息，然后根据这些信息做药品下单。
这两步流程我通过ReAct来实现的，大概是让它智能的判断是否已经完全收集患者信息了，如果是就总结相关内容调用function call下单。 它的智能判断让我瞠目结舌： 有时候患者没说完话就下单了，有时候患者说了很多明确表达说明了，还不下单。。 这个部署在生产环境上，肯定是不过关的。
如果将流程拆分出来，不让智能体React来判断，而是我通过固定的编码流程处理患者信息的手、让用户确认、然后在下单。改造之后的流程就完全没有问题了。
!
多智能体合作
思考过这样的问题吗：coze、dify这些智能体工作流框架已经很好了，为什么还要进行代码开发？尤其是随着越来越多的智能体框架出现，再加上OpenAI也开源了自己的多智能体swarm框架。
原因是：当场景细分、流程拆分后。 要将他们拼凑起来才可以完成更复杂的业务场景。只有工作流的话，简单场景没问题，复杂场景则开发的灵活度就较差了。
最后
ReAct的缺点是： 让一个LLM做了太多的事情了，尤其是在意图识别时会有产生很多偏差。 解决方案： 1. 不要按照数据拆分，按照场景拆分，先搞定最细粒度的场景。 2. 对小场景中的流程进行细致的节点拆分，将固定的流程先行标准化，从而降低大模型在选择过程中出现的不稳定性。 3. 逐步叠加小场景，通过多智能体的协同合作，最终构建出完整的大场景。