杠精派
派聪明
0/512

热门评论

2026年06月08日 10:43
引用原文:使用 Redis 缓存文件元信息与上传分片,结合 MinIO 实现大文件分片上传与断点续传,优化后 1GB 文件上传耗时由 15s 降至 3s。
@派聪明 这个上传耗时的时间计算的整体链路是什么,不包括解析吗
点赞
回复3 取消回复
派聪明 2026年06月08日 10:44
在基于 RAG 的知识库系统中,这条链路非常明确:**上传耗时是不包括后续的文档解析、切片和向量化的。** 整个业务流程采用了**异步解耦**的设计,具体的整体链路可以分为以下两个独立阶段: ### 第一阶段:大文件上传链路(即简历中的3s耗时) 这个阶段的核心任务是**将文件完整、可靠地传输到服务器的对象存储中**,并记录元信息。它的链路如下: 1. **前端分片**:前端计算文件指纹(如 MD5),并将1GB的大文件切分为多个小块(分片),开启多线程并发上传。 2. **状态记录**:后端收到分片后,使用 **Redis BitMap** 高效记录各个分片的上传状态,MinIO负责存储这些分片内容。 3. **合并确认(终点)**:所有分片上传完毕后,触发合并接口,将零散分片在 MinIO 中组装成完整的1GB原始文件。 4. **快速响应**:合并成功后,后端立即给前端返回“上传成功”的响应。**这整个网络传输与合并的过程,就是简历中优化的3s耗时。** ### 第二阶段:文档异步处理链路(不包含在上传耗时内) 上传接口返回后,系统通常会通过**消息队列(如 Kafka)**触发一个完全异步的后台任务来处理这个大文件。这部分耗时往往很久,如果在主线程做会导致接口超时。它的链路如下: 1. **事件触发**:文件合并成功后,向后端发送一个“文件就绪”的事件(或投入 MQ)。 2. **文档解析**:调用解析工具(如 Apache Tika、LiteParse)读取1GB 文件的内容,提取纯文本和 OCR 信息。 3. **文本切片**:按照一定策略(如滑动窗口)将长文本切分成多个语义块。 4. **向量化入库**:调用大模型(如阿里 Embedding)将文本块转化为向量数据,并存入 Elasticsearch等向量数据库中供后续检索。 **总结:** 简历中“15s降至3s”的指标,纯粹指代**“文件分片 -> 并发传输 -> 合并落盘”**的网传与 IO 过程。将耗时的“解析与向
点赞
回复 取消回复
展开剩余 2 条回复

57 条评论

2026年06月08日 10:43
引用原文:使用 Redis 缓存文件元信息与上传分片,结合 MinIO 实现大文件分片上传与断点续传,优化后 1GB 文件上传耗时由 15s 降至 3s。
@派聪明 这个上传耗时的时间计算的整体链路是什么,不包括解析吗
点赞
回复3 取消回复
派聪明 2026年06月08日 10:44
在基于 RAG 的知识库系统中,这条链路非常明确:**上传耗时是不包括后续的文档解析、切片和向量化的。** 整个业务流程采用了**异步解耦**的设计,具体的整体链路可以分为以下两个独立阶段: ### 第一阶段:大文件上传链路(即简历中的3s耗时) 这个阶段的核心任务是**将文件完整、可靠地传输到服务器的对象存储中**,并记录元信息。它的链路如下: 1. **前端分片**:前端计算文件指纹(如 MD5),并将1GB的大文件切分为多个小块(分片),开启多线程并发上传。 2. **状态记录**:后端收到分片后,使用 **Redis BitMap** 高效记录各个分片的上传状态,MinIO负责存储这些分片内容。 3. **合并确认(终点)**:所有分片上传完毕后,触发合并接口,将零散分片在 MinIO 中组装成完整的1GB原始文件。 4. **快速响应**:合并成功后,后端立即给前端返回“上传成功”的响应。**这整个网络传输与合并的过程,就是简历中优化的3s耗时。** ### 第二阶段:文档异步处理链路(不包含在上传耗时内) 上传接口返回后,系统通常会通过**消息队列(如 Kafka)**触发一个完全异步的后台任务来处理这个大文件。这部分耗时往往很久,如果在主线程做会导致接口超时。它的链路如下: 1. **事件触发**:文件合并成功后,向后端发送一个“文件就绪”的事件(或投入 MQ)。 2. **文档解析**:调用解析工具(如 Apache Tika、LiteParse)读取1GB 文件的内容,提取纯文本和 OCR 信息。 3. **文本切片**:按照一定策略(如滑动窗口)将长文本切分成多个语义块。 4. **向量化入库**:调用大模型(如阿里 Embedding)将文本块转化为向量数据,并存入 Elasticsearch等向量数据库中供后续检索。 **总结:** 简历中“15s降至3s”的指标,纯粹指代**“文件分片 -> 并发传输 -> 合并落盘”**的网传与 IO 过程。将耗时的“解析与向
点赞
回复 取消回复
展开剩余 2 条回复
受伤的指甲油 2026年06月07日 23:18
引用原文:RRF
是啥?@派聪明
点赞
回复1 取消回复
派聪明 2026年06月07日 23:19
RRF 是 **Reciprocal Rank Fusion(倒数排名融合)** 的缩写。它是一种在 RAG(检索增强生成)知识库中常用的多路搜索结果融合算法。 简单来说,它的核心思想是:**“一个文档越是在多个不同的检索排名列表里排在靠前的位置,它的最终综合得分就应该越高。”** 在传统的企业级搜索中,我们通常会同时使用**语义检索(KNN)**和**关键词检索(BM25)**。但它们返回的分数量纲不一致(例如 BM25 可能是几十上百,而向量相似度往往是0 到1之间的小数),不能简单地相加。RRF 就是为了解决这个问题而诞生的。 **它的计算原理非常简单:** 通过公式 `RRF_Score = Σ (1 / (k + rank_i))` 来计算。 - `rank_i` 是文档在某个检索结果中的排名(比如排第1 名就是1)。 - `k` 是一个常数(通常设为60),用于平滑排名靠后的文档对分数的影响。 系统会计算出所有文档的综合得分,并按得分重新排序。 **RRF 的主要优势:** 1. **解决量纲不一致**:它完全屏蔽了原始得分大小的差异,只看重“排名先后”。 2. **提升召回准确率**:避免了简单“取交集”导致的相关文档漏掉的问题。它能很好地把语义相关的文档和包含特定关键词的文档结合起来。 在实际开发中,现代搜索引擎(如 Elasticsearch8.x 版本之后)已经原生支持在一次查询中同时进行向量和关键词搜索,并直接指定使用 RRF算法进行自动融合排序,无需开发者手动编写代码计算。
点赞
回复 取消回复
  ᶘ ᵒᴥᵒᶅ   2026年05月18日 17:00
引用原文:构建 RAG 效果评测与模型对比机制,设计多层次文档匹配算法评估检索质量,针对 bge、qwen 等向量模型输出 Precision、Recall、F1、MRR 等指标,为优化提供量化依据。
@牌聪明
点赞
回复 取消回复
沉喧 2026年04月24日 15:07
引用原文:集成 RAG 检索增强架构,利用 Embedding API 生成文档向量,结合 Elasticsearch 语义检索,较关键词搜索准确率提升 40%+;通过 Kafka 异步结构文档的解析、向量化和存储,从而提升系统的整体 QPS。
40%的准确率怎么实现的,具体流程是什么,使用了什么软件进行QPS测试
点赞
回复 取消回复
胖墩 2026年04月20日 20:11
引用原文:结合 MinIO 实现大文件分片上传与断点续传,将 1GB 文件上传耗时由 15s 优化至 3s
@派聪明 这里的具体的数值是怎么计算得到的呢
点赞
回复1 取消回复
怡然的鞋垫 2026年05月27日 14:36
吹N得到的
点赞
回复 取消回复
muximin 2026年04月07日 19:39
引用原文:文档数据库 :存储未经再次切分的‘父文档’块,并为每个父文档生成一个唯一的ID。在‘子切片’存入向量库时,我会将它所属的‘父文档’ID 作为元数据(Metadata)一同存储。
@派聪明 这里的“父文档”块是不是存储在文件分块信息表中的
点赞
回复 取消回复
过时的草莓 2026年04月01日 15:50
引用原文:融合通义千问 Embedding 模型实现 2048 维向量转换
什么意思@派聪明
点赞
回复1 取消回复
派聪明 2026年04月01日 15:53
这句话的意思是:**通过集成阿里巴巴通义千问(Qwen)的Embedding模型,将文本数据转换为2048维度的数学向量表示**。具体解析如下: --- ### 1. **核心概念拆解** - **通义千问Embedding模型** 阿里巴巴开发的文本嵌入模型,能将文本(如句子、文档)转化为高维向量。这些向量在数学空间中捕捉语义关系,使相似文本的向量距离更近(例如"快乐"和"高兴"的向量相近)。 - **2048维向量转换** 模型输出的每个文本被表示为一个包含**2048个浮点数**的向量。这个维度是模型预定义的输出格式,决定了向量空间的复杂度和语义表示的精细程度。 --- ### 2. **技术实现逻辑** - **转换过程** 输入文本 → 通义千问Embedding模型 → 输出2048维向量。 例如:用户查询"如何提升代码质量" → 模型生成一个长度为2048的向量数组。 - **应用场景** - **RAG系统**(如参考资料中多个项目): 将企业文档、知识库内容转换为2048维向量存储,用户提问时同样转换为向量,通过计算向量相似度(如余弦相似度)检索最相关的文档片段。 - **语义检索**: 替代传统关键词搜索,实现更精准的语义匹配(如参考资料[5]提到医疗文献检索相关性提升34%)。 --- ### 3. **为什么选择2048维?** - **性能与精度的平衡**: 参考资料[5][9]显示,通义千问Embedding模型在多语言任务(如MTEB评测)中超越OpenAI、谷歌同类模型,2048维是其优化后的标准配置,兼顾语义表达能力和计算效率。 - **任务适配性**: 参考资料[8]提到,模型支持**自定义维度**,但2048维是针对企业级知识库、跨语言检索等场景的推荐配置,确保复杂语义的充分表示。 --- ### 4. **实际应用价值** - **提升检索准确率**: 如参考资料[7]所述,高质量向量转换使RAG系统的检索准确率提升40%,尤其在专业领域(如医疗、代码分析)效果显著。 - **多语言支持**: 参考资料[9]指出,该模型支持超100种语言,2048维向量能统一不同语言的语义空间,实现跨语言检索。 --- ### 总结 这句话描述的是**利用通义千问Embedding模型将文本转化为2048维向量的技术过程**,核心目的是为语义检索、RAG系统等提供高精度的文本表示能力,从而提升AI应用的智能性和准确性。
点赞
回复 取消回复
洛兮 2026年04月01日 00:01
引用原文:使用 Redis 缓存文件元信息与上传分片,结合 MinIO 实现大文件分片上传与断点续传,优化后 1GB 文件上传耗时由 15s 降至 3s。
这里的优化具体指的是什么
点赞
回复 取消回复
聪明的口红 2026年03月30日 00:03
引用原文:设计选择,目的是为了区分“找不到”和“没权限”,从而提供更智能的用户体验
后续上传的文档是不是还要在进行向量化,这部分是怎样解决的?
点赞
回复1 取消回复
聪明的口红 2026年03月30日 00:04
@派聪明
点赞
回复 取消回复
chentt 2026年03月28日 14:10
引用原文:负责实现工作流运行时待办人动态修改功能,通过事件驱动同步多源数据,并开发 WebSocket + 短信双通道通知机制,提升消息触达率
@派聪明 这个要在怎么实现
点赞
回复1 取消回复
派聪明 2026年03月28日 14:11
要实现工作流运行时待办人动态修改功能,并配合事件驱动数据同步和双通道通知机制,需分三步设计系统架构。以下是具体实现方案: --- ### **一、核心功能实现** #### 1. **动态待办人修改** - **技术方案**: - 使用工作流引擎(如Activiti/Camunda)的**任务节点动态重分配API**,通过`TaskService.setAssignee(taskId, newUserId)`实时修改待办人。 - **事务一致性**:结合数据库事务确保修改操作与数据同步的原子性(例如:先更新任务表,再触发事件)。 - **权限校验**:修改前校验操作人权限(如是否为流程发起人或管理员),避免越权操作。 #### 2. **事件驱动数据同步** - **事件流设计**: ```mermaid graph LR A[待办人修改] --> B(发布事件 TaskAssignedEvent) B --> C{消息队列} C --> D[数据源A同步] C --> E[数据源B同步] C --> F[通知系统触发] ``` - **事件定义**: ```java public class TaskAssignedEvent { private String taskId; private String oldAssignee; private String newAssignee; private Map<String, Object> extraData; // 存储流程上下文 } ``` - **多源同步**: - 消息队列(如Kafka/RabbitMQ)订阅事件,各数据源服务(如用户中心、任务系统)消费事件并更新本地数据。 - **数据一致性**:采用最终一致性模型,通过事件重试机制(如死信队列)确保同步成功。 --- ### **二、双通道通知机制** #### 1. **WebSocket实时推送** - **实现方案**: - **前端**:建立WebSocket连接,订阅`/topic/task-assign`频道。 - **后端**:使用Spring WebSocket或Socket.IO,在事件触发时推送消息: ```java @SendTo("/topic/task-assign") public NotificationMessage notifyAssignChange(TaskAssignedEvent event) { return new NotificationMessage( "您的待办任务已重新分配", "任务ID: " + event.getTaskId() ); } ``` - **在线状态管理**:通过Redis记录用户在线状态,仅推送至在线用户。 #### 2. **短信通知(离线兜底)** - **集成流程**: 1. **触发条件**:用户离线(WebSocket推送失败)或任务优先级高。 2. **短信发送**:调用第三方短信网关(如阿里云SMS): ```java @RabbitListener(queues = "sms.queue") public void sendSmsNotification(TaskAssignedEvent event) { String phone = userService.getPhone(event.getNewAssignee()); smsService.send(phone, "任务【" + event.getTaskId() + "】已分配给您"); } ``` 3. **消息可靠性**: - 使用消息队列异步发送,避免阻塞主流程。 - 增加重试机制(如RabbitMQ的死信队列)。 --- ### **三、关键优化点** 1. **性能优化**: - **高频修改场景**:引入**本地缓存**(Redis)存储任务分配状态,减少数据库查询。 - **通知延迟**:WebSocket推送采用**异步非阻塞**(如CompletableFuture),短信发送走独立线程池。 2. **容错机制**: - **事件重试**:对同步失败的数据源记录错误日志,定时重试。 - **降级策略**:短信服务不可用时,改用邮件或站内信替代。 3. **安全控制**: - **操作审计**:记录所有待办人修改操作到日志表,包含操作人、时间、变更详情。 - **敏感操作**:高优先级任务修改需二次验证(如短信验证码)。 --- ### **四、技术栈参考** | 模块 | 推荐技术 | |---------------|----------------------------| | 工作流引擎 | Activiti 7 / Camunda 7 | | 消息队列 | Kafka / RabbitMQ | | 实时通信 | Spring WebSocket / Socket.IO| | 短信服务 | 阿里云SMS / Twilio | | 缓存 | Redis(存储在线状态/任务数据)| | 数据同步 | 事件驱动 + 最终一致性 | --- ### **五、效果预期** - **动态修改**:待办人变更响应时间 < 500ms。 - **通知触达**:WebSocket在线用户实时通知,离线用户短信覆盖率达99%+。 - **数据一致性**:事件驱动模式下,多源数据同步延迟 < 3s。 通过事件解耦核心业务与通知逻辑,结合双通道覆盖不同场景,可实现高可靠、低延迟的工作流待办管理。
点赞
回复 取消回复

目录