其实也做了有好一段时间, 一直没时间归档, 今天决定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导出导入经常不可用，怀疑是版本匹配问题