- 1hive解析json_hive json解析函数
- 2一文读懂火爆的AI Agent（智能体）
- 3手撕数据结构---------顺序表和链表
- 4面试篇-SpringBoot自动配置原理_面试springboot自动配置原理
- 5【LSTM分类】长短时记忆神经网络结合多头注意力机制LSTM-Mutilhead-Attention数据分类【含Matlab源码 4266期】_长短效神经网络
- 6【无人直播】录播分析-虚拟摄像头_android虚拟摄像头无人直播
- 7JetBrains学生正版全家桶授权（大学4年免费）获取教程-idea学生免费许可解决方法_jetbrains学生认证
- 8详解数据结构之队列、循环队列(源码)
- 9逆向工程实验_lab0（密码学算法逆向）_密码逆向工程
- 10OpenHarmony教程指南—ArkTS时钟_arkts getdefaultdisplay
企业级多Agent智能知识库调研_企业级agent
赞
踩
1、Milvus、Faiss、Weaviate、Elasticsearch、MongoDB
| 维度 | Milvus | Faiss | Weaviate | Elasticsearch | MongoDB |
|---|---|---|---|---|---|
| 单机部署资源推荐 | CPU: 多核（≥4核）, 内存: ≥16GB, 存储: SSD | CPU: 多核（GPU加速需额外GPU资源）, 内存: 根据数据集大小, 存储: SSD | CPU: 多核（≥4核）, 内存: ≥8GB, 存储: SSD | CPU: 多核（≥2核）, 内存: ≥4GB, 存储: SSD | CPU: 多核（推荐≥4核）, 内存: 根据数据集大小, 存储: SSD |
| 单机部署方式 | 容器化（Docker），支持多种操作系统 | 库文件，需集成到现有应用或框架中 | 容器化（Docker），支持多种操作系统 | 容器化（Docker），支持多种操作系统 | 容器化（Docker），支持多种操作系统 |
| 是否支持Docker集群部署 | 是（支持Kubernetes等容器编排工具） | 否（主要通过多实例或分布式框架支持，需额外配置） | 是（支持Kubernetes部署） | 是（支持Docker Swarm或Kubernetes等） | 是（支持Kubernetes等） |
| Docker单机性能 | 高，支持资源限制和隔离 | 高（GPU加速显著，但需额外配置） | 高，支持资源限制和隔离 | 高，支持资源限制和隔离 | 高，支持资源限制和隔离 |
| Java支持友好性 | 友好（提供Java SDK） | 一般（主要通过Python接口，需额外Java包装） | 友好（提供Java客户端库） | 友好（Java API支持） | 友好（Java Driver支持） |
| 实时性 | 高（支持实时索引与查询） | 中等（主要关注批量处理，但可通过设计实现实时） | 高（支持实时索引与查询） | 接近实时 | 高（支持实时查询和索引） |
| 特定用例 | 推荐系统、图像/视频检索、NLP | 图像搜索、文本搜索、推荐系统 | 语义搜索、问答系统、多模态内容管理 | 文档搜索、日志分析、实时数据分析 | 文档存储、实时数据分析、物联网（IoT） |
| 可视化客户端 | 有（Milvus Insight） | 无（主要通过集成到应用中） | 有（Weaviate UI） | 有（Kibana, Grafana等插件） | 有（MongoDB Compass） |
| 是否支持全文检索 | 否 | 否（专注于向量检索） | 否（但支持语义搜索） | 是 | 是（内置全文搜索引擎） |
| 是否支持向量检索 | 是 | 是 | 是 | 否（通过插件或外部系统集成可能支持） | 否（但可通过插件或外部系统集成支持） |
| 是否支持混合检索 | 是（通过插件或外部系统集成） | 否（专注于向量检索） | 是（支持多模态检索） | 否（但可结合全文和向量检索的外部解决方案） | 是（结合全文和复杂查询的能力） |
| 向量检索精确度对比 | 高（优化针对向量数据的检索算法） | 高（Facebook AI Research 的专注产品） | 中等至高（取决于具体实现和向量处理策略） | 低（需通过插件或外部系统集成，精确度依赖于集成质量） | 低（需通过插件或外部系统集成） |
| 开源公司 | Zilliz | Facebook AI Research | Semi-Technologies | Elasticsearch BV（现属于Elastic公司） | MongoDB Inc. |
Milvus分析，Milvus官方基准测试
Milvus
- 文档多，中文支持、Java支持更加友好
- 组件结构清晰，学起来更加容易，更容易上手
- 集群组件多但是模块化强，且耦合度很低，更容易排查问题
- 单机Docker部署简单，并且也能有不错的性能表现
- 国产，2019年全球首个开源的向量数据库
6、Weaviate、Drant易用性相对来说好一点，文档比较少
官方基准测试
- 使用相应的服务器配置通过Helm启动Milvus实例。
- 通过Milvus GO SDK连接至Milvus实例并获取相应的测试结果。
- 创建一个集合。
- 插入100万个SIFT向量。使用HNSW索引并将索引参数配置为将 M 设为 8，将 efConstruction 设为 200。
- 加载该集合。
- 以不同的并发数和搜索参数 nq=1, topk=1, ef=64 进行搜索，每次并发的持续时间至少为1小时。
单机模式
12核CPU、16G内存
| Milvus | QPS | RT(TP99) / ms | RT(TP50) / ms | fail/s |
|---|---|---|---|---|
| 2.1.0 | 4287 | 104 | 76 | 0 |
| — | — | — | — | — |
| 2.2.0 | 7522 | 127 | 79 | 0 |
| — | — | — | — | — |
集群模式单个QueryNode节点
分别8核、12核、16核、32核CPU，8G内存
| CPU cores | Concurrent Number | QPS | RT(TP99) / ms | RT(TP50) / ms | fail/s |
|---|---|---|---|---|---|
| 8 | 500 | 7153 | 127 | 83 | 0 |
| 12 | 300 | 10248 | 63 | 24 | 0 |
| 16 | 600 | 14135 | 85 | 42 | 0 |
| 32 | 600 | 20281 | 63 | 28 | 0 |
集群模式扩展副本集性能测试
8核、8G内存，分别1、2、4、8副本
| Replicas | Concurrent Number | QPS | RT(TP99) / ms | RT(TP50) / ms | fail/s |
|---|---|---|---|---|---|
| 1 | 500 | 7153 | 127 | 83 | 0 |
| 2 | 500 | 15903 | 105 | 27 | 0 |
| 4 | 800 | 19281 | 109 | 40 | 0 |
| 8 | 1200 | 30655 | 93 | 38 | 0 |
高并发测试总结
Milvus在数据量百万、查询不是特别复杂的情况下，可以轻松支持到2000-4000QPS。
3、LLM大模型性能分析
1、模型量化
比如FP16 34B模型，占用2字节 * 34 * 10 ^9 = 64G，这里需要至少64G显存加载，运行过程还会增加一些中间结果。半精度浮点数FP16中的部分参数如果能量化成INT8类型，需要的显存减半。GPTQ、GGML量化方法，Qwen-7B-Chat-In8模型加载算下来需要6.53G显存。
2、连续批处理
连续批处理文章，包含性能测试 https://zhuanlan.zhihu.com/p/681147592
3、并发加速部署方式
vLLM或者LightLLM
4、硬件怎么选
并发部署方案 + 量化方案来确定大概需要多少显存，并决定使用哪种GPU
5、大模型并发目前结论
大模型并发处理能力完全取决于GPU推理能力。200人的并发，每人发送100Token，服务器通过连续批处理方式持续不断地推理回答，按照500Token/s的回答速度，输出200*100=2wToken，最起码也需要40S。这还是建立在通过VLLM框架优化部署、采用适当的量化模型和选用GPU服务器的情况下。所以，多少人请求都没有问题，问题在于对于每个人的请求，需要比较长的推理时间。如果显存不够，过多的请求会直接导致模型OOM。
开源大模型为啥处理速度这么快，比如文心一言每日处理Token高达上千亿，除了技术方面的优化手段之后，最大的决定因素还是数以万计的GPU算力。
4、Agent知识库
Agent知识库设计
Dify快速建立知识库
1、Dify可以在线批量上传文档，进行数据分段手动调整每段内容的功能。
2、Dify提供全文检索、向量检索等功能，并且可以在线测试文档召回。
3、Dify召回文档之后，可以通过工具或者http接口收集数据，把Query + 召回文档 + 工具数据 + Http数据 + Prompt模板统一交由LLM分析处理。
Dify知识库功能模块化改造
Dify在线文档处理流程
文档批量上传 -> 文档按字数分段 -> 展示分段文档 -> 手动调整文档内容 -> 选择LLM向量模型 -> 向量数据和文档数据存储 -> 文档召回测试。
Dify在线文档处理流程是否可以改造成下面这种
文档批量上传 -> 文档预处理【内容过滤，去除无效内容，压缩到30% 比如2w字到6000字】 ->文档按字数分段 -> 文档段处理(如果有必要可以通过选择方式选定代码处理模板)【提取每段标题、语义、摘要、关键词】 ->展示分段文档 -> 手动调整文档内容 -> 选择LLM向量模型选择索引方式【ES全文检索、或者Milvus向量检索、或者两者混合检索】-> 向量数据和文档数据存储【前端配置es、milvus地址后，建立索引并写入到数据库】 -> 文档召回测试。
Dify 离线文档处理，文档辅助处理后台服务
增加离线文档处理页面 -> 定时任务配置比如接口地址、存储地址、索引方式 -> 定时调用后台接口，并在页面展示文档处理的结果。
文档加载定时任务 -> 文档处理辅助服务加载文档 -> 文档预处理【内容过滤，去除无效内容，压缩到30% 比如2w字到6000字】 ->文档按字数分段 -> 文档段处理(如果有必要可以通过选择方式选定代码处理模板)【提取每段标题、语义、摘要、关键词】 ->展示分段文档 -> 手动调整文档内容 -> 选择LLM向量模型选择索引方式【ES全文检索、或者Milvus向量检索、或者两者混合检索】-> 向量数据和文档数据存储~~【前端配置es、milvus地址后，建立索引并写入到数据库】~~ -> 文档召回测试。
Agent 知识库智能问答
Agent知识库系统部署方案
如果数据量千万，性能、扩展性、可用性要求不高，可以采用简化部署方案。
| 软件 | Cpu | 内存 | 磁盘 |
|---|---|---|---|
| Milvus、Etcd、Minio | 8核 | 16G | 1T SSD |
| Elasticsearch/kibana | 8核 | 16G | 1T SSD |
| 高性能LLM推理服务器，多卡或者多服务器负载均衡 |
如果数据量上亿，性能、扩展性、可用性有一定要求，可以采用下面的部署方案。
| 软件 | Cpu | 内存 | 磁盘 |
|---|---|---|---|
| Milvus、Etcd、Minio | 8核 | 16G | 1T SSD |
| Milvus、Etcd、Minio | 8核 | 16G | 1T SSD |
| Milvus、Etcd、Minio | 8核 | 16G | 1T SSD |
| Pulsar、Minio | 8核 | 16G | 1T SSD |
| Elasticsearch/kibana | 8核 | 32G | 1T SSD |
| 高性能LLM推理服务器，多卡或者多服务器负载均衡 |
如果涉及到多Agent设计且数据量几十亿不止的情况下，后续还会根据企业不同的需求，接入各种各种的数据。并且对系统的可用性、扩展性、性能有较高要求，需要需要采用分布式集群部署方案，下面的部署可以按需扩展。
| 软件 | Cpu | 内存 | 磁盘 |
|---|---|---|---|
| Elasticsearch | 8核 | 16G | 1T SSD |
| Elasticsearch | 8核 | 16G | 1T SSD |
| Elasticsearch | 8核 | 16G | 1T SSD |
| Kibana | 2核 | 4G | 60G |
| Etcd1 | 4核 | 8G | 60G |
| Ectd2 | 4核 | 8G | 60G |
| Etcd3 | 4核 | 8G | 60G |
| Minio1 | 4核 | 8G | 1T SSD |
| Minio2 | 4核 | 8G | 1T SSD |
| Minio3 | 4核 | 8G | 1T SSD |
| Minio4 | 4核 | 8G | 1T SSD |
| Milvus QueryNode1 | 8核 | 8G | 60G |
| Milvus DataNode1 | 8核 | 8G | 60G |
| Milvus IndexNode1 | 8核 | 8G | 60G |
| Pulsar或者Kafka | 8核 | 8G | 100G |
| 高性能LLM推理服务器，多卡或者多服务器负载均衡 |
分布式部署服务器拓补图
