其实也做了有好一段时间, 一直没时间归档, 今天决定mark一下.

由于工作需要, 最终效果需要具备移植性, 所以我这里Dify平台也尝试了本地部署, 以保证最终可交付.

准备就绪, 接下来就是创建ChatFlow

先捋一下编排构思:

• 目标是实现即时的数据查询统计分析
• RAG提供知识库, 由LLM自行推断数据查找办法
• 提供数据查询接口
• 结果渲染(列表or图表)

Dify当前是原生支持http请求节点, 安装工具也能够支持database. 所以取数问题不大. 刚开始先直连数据库做个demo, 大概流程如上图所示

实际调试下来, 需要增加很多的优化节点才能保证有一个比较高的准确性, 上图是花了近一天时间调试下来的效果, 而且还没有足够完善, 比如数据库查询这一个环节, 有几率会出现生成的SQL无法执行, 需要增加重试机制(不是简单的重新执行, 而是把错误结果作为BuildSQL的一部分进行重试)

贴几处提高准确率办法:

1. 提取关键字再进行知识检索能提高检索准确率

2. 自动编写SQL, 需要对做好限定条件, 且保留sql到最终回复(便于持续优化)

3. 固定逻辑写Python处理, 而不是全靠LLM

4. 保留好异常结果(不要过于依赖后台预览, 发布后仍然需要持续优化)

整体用下来基本都是拖拉拽, 测试, 调整prompt, 测试, 增删节点,调整promtp, 测试……

目前有发现影响比较大的问题: 预览测试失败时, 失败节点如果在循环体内, 无法显示是循环体内的哪个节点有问题, 这个超级不方便(我用的1.3.0版本)

多个Echarts结果无法连结同一个变量聚合器, 导致柱状图/饼图/线型图都需要分别做结果处理

DSL导出导入经常不可用，怀疑是版本匹配问题