介绍

SuperBI是我根据鱼皮的bi项目改编而来，基础业务逻辑没有变动，对于消息队列以及大模型应用方向上增添了我最近学习到的内容，设计上可能不够完美，之后会逐渐改进。

github连接

原项目的缺陷

原项目的系统设计大致如下：

image-20250612111005360

就功能实现而言，系统设计上没有问题，重点关注在gpt接口吞吐量不大，因此这里使用了消息对立做削峰填谷、做背压，防止过多的流量进入gpt。

但是，这样的设计主要有几个缺陷：

  • 采用线程池的方式消费清洗以及压缩任务，可能会出线任务丢失的情况，及线程池没有持久化的机制，虽然可以通过任务状态，定时获取未完成的任务进行重新消费，但是这样就需要额外的维护，提高系统复杂度了
  • 同时这两个任务通过单机部署，就会出现耦合性以及扩展性的问题(具体情况具体分析，我这里按照未来需要扩展以及大流量的场景分析了)
  • GPT消费的服务过于简单，会有各种问题，常见的有大模型幻觉、提示词注入等，对最终结果的生成质量有一定影响
  • 额外的，一些新的大模型框架可以用上，比如Langchain等等

新设计

我主要对几个模块进行了拓展：

  • 拆分任务：数据上传、数据清洗+数据压缩、ai生成 三个任务(其实还可以再拆，微服务等思想)
  • 通过kafka形成任务链，解耦每个功能模块，同时提供重试策略以及任务状态机
  • 使用Langchain构建多个agent
  • 通过Multi agents 投票以及 reasking机制来减少幻觉等情况

image-20250612110108521

不足

新设计上虽然引入了很多大模型幻觉处理等流程，但是思考下来之后依旧有很多问题：

  • token消耗量很大，在multi agents生成过程成可能会有多轮反复的生成，这就会导致出现一个任务出现大量token的损失
  • 评分机制过于粗糙，我这里直接采用其他模型对于某个模型的评分作为标准，但是这种方式还应该验证可行性
  • 对于一些promot注入等情况应当加以注意

不足的解决方案

对于以上的不足点，我自己想到了一些解决方案：

  • 首先输入上尽可能压缩，减少token(可以参考一些论文)
  • 可以通过小模型，先对用户输入进行一个预输出，告知接下来的输出结果是怎么样的，如果用户不满意，就可以进行迭代，减少反复进行大任务生成

结语

对于大模型安全方向上，我还没有深入的学习，但这是不可避免需要接触的，写这篇文章也算是一个在ai应用上学习的阶段性的成果，加了一些自己在系统设计上的思考🤔，如果本文对你有帮助，希望可以帮忙推广，如果你对这一块的系统设计有独到见解，可以在下方留言，也可以添加我个人的微信或者qq。

参考文献：
When One LLM Drools, Multi-LLM Collaboration Rules