Coze案例 | 饮食助手：如何在Coze进行知识库调优

Coze确实是练习搭建Agent的一个比较好的平台，理论也要结合实践，所以最近再练习搭建智能体和智能应用。

头几天自己尝试搭建一个饮食管理应用的时候，屡屡碰壁，数据库和工作流总是有bug，而且感觉工作流有些节点的逻辑跟我的直觉不一样，所以还是按部就班一点点实践吧。

首先是搭建一个最简单的知识库LLM，创建一个知识库，让智能体可以自己检索知识库里的信息去回答用户的问题，也就是RAG。

以及进一步如何调整LLM的输出准确性。

比较常见的需要用到知识库的Agent场景是协助客服，知识库的内容也就是过去记录的常见Q&A。我这里去网上随便找了一段关于饮食的资料，作为知识库的素材。

在Coze创建一个知识库，首先会让你上传知识库资料，如果保持默认选项来到“分段预览”这里，会发现分出来的都是一大段的内容。

这里的操作步骤作用不仅仅是提取文字、数据预处理，分段也会影响后续LLM的性能。参考之前《10分钟快速了解RAG是什么》的RAG基础原理文章可以知道，数据分的段落就是后续知识库根据问题返给LLM的资料片段。

也就是说，你在这里分的段落越大，后续哪怕只有一句话跟用户问题相关，知识库也会把整个段落都发给LLM，这样不仅降低精度，也可能影响性能。

所以优化的第一个机会就是，在第2步里的“分段策略”，选择自定义策略，可以根据各种分段标识符来分段。

比如我这里本地doc文档里，段落间会有换行，知识库就可以根据换行来进行分段。也可以选择一些特殊符号，比如 {}、| 等标识。

这样的分段就更加细致了，有利于后续知识库的检索。

创建完知识库后，我们创建一个工作流，里面插入“知识库检索”节点，看到右边三个变量。

搜索策略里，语义搜索：理解关键词真正含义（适用于模糊提问）全文搜索：搜索关键词（适用于特定术语等精确信息查询）

最大召回数量即用户提问后，返回的知识库检索段落数量。最小匹配度即返回资料的相关性门槛。

我们引用刚才创建的知识库后，试运行该节点，点开运行结果可以发现，返回的知识片段还是比较精确的。

因为这个案例比较简单，所以只提一些细小的可能会出bug的点。

首先是人设逻辑这里，注意最左侧Prompt栏里，如果要在prompt里引用工作流，需要输入{{}}，就会跳出可引用的工作流选项。

但此外，如果只是引用变量或插件的话，可以随意一些。在prompt里点名什么时候用什么变量、什么插件，也可以让LLM的输出更精确。

前面我们创建的是工作流，还有一种叫对话流。二者比较明显的区别是工作流无记忆功能，而对话流有记忆功能。

工作流适用的场景是处理独立的功能性任务，比如批量生成内容、自动化数据处理等。比如只要给定一个主题，就自动生成文章，这种不需要交代前后对话历史的任务。

而这里搭建的智能体偏向于和用户聊天，所以需要改为“对话流”模式。

我们在资源库里找到创建的工作流，可以快捷切换成对话流。切换后，点进工作流里的大模型节点，就会发现右边配置的“输入”部分，多了勾选对话历史的选项。

根据用户提问，去检索知识库的信息，然后交给LLM生成回答，这个过程看似很简单，但还有一些可优化的步骤。

首先是用户提问。用户提问可能会存在模糊不清、指代不明的情况。上一步记录对话历史能够优化一部分，也可以通过对话流里的“意图识别”节点进行细分。

增加“意图识别”的节点后，可以识别用户输入，这里举例分为碳水、蛋白质和膳食纤维这常见的营养成分类别，当然相应的知识库也有进行细分。

通常在“意图识别”的节点后，可以再加一个“变量聚合”，把三种可能的输出给整合到一个变量进行输出，这样如果工作流后续还要进行处理的话，也更方便管理。

变量聚合的规则是“返回每个分组中第一个非空的值”，因此这里在变量的排序上也存在影响。一个意图识别的节点肯定是只会输出一个变量，但是如果复杂情况下涉及多个意图识别、多种输入，就需要把你更像输出的变量排在前面了。

如果用户的提问是不相关的问题，可以增加一个问答节点，询问用户到底想问什么，再引入刚才的三个分类。如果还是不符合用户的预期，再通过“文本处理”节点，对用户说明原因即可。

有时候我们需要添加用户变量，例如需要根据用户自己的口味偏好来推荐饮食。

但是在工作流里的大模型节点，会出现无法引用“用户变量”的问题。

这时候需要点击大模型节点的“试运行”，然后选择关联我们当前的智能体，这样才能读取该智能体的“用户变量”。

我理解的逻辑是，虽然你是在创建该智能体的界面里创建的工作流，但是逻辑还是被统一设定为，工作流是外部的流程，除非你自己设置，否则默认不属于任何一个智能体，自然也读不到智能体里面的用户变量了。

只要关联智能体后，再点击大模型节点的配置项，就可以引用绑定用户变量了。

一个简单的案例介绍，会持续深入的更新Coze搭建Agent的分享。