2025 年 06 月

RocketMQ 使用方案

RocketMQ 在项目中用于两个场景：文档分块异步处理和用户反馈异步持久化。 选型上，事务消息是核心刚需——文档分块需要保证"数据库写 + 消息发"的原子性，Kafka 的事务消息面向流处理场景不太匹配，RabbitMQ 没有原生事务消息需要自己实现可靠投递。延迟消息能力作为后续摄入失败自动重试的
作者：old wang
分类： RAG

SSE 流式输出实现方案

概述 SSE（Server-Sent Events）流式输出是 RAG 回答链路中直接面向用户的最后一环——将 LLM 逐 token 生成的回复实时推送到前端，让用户感知到"正在回答"而不是盯着白屏等待。 选择 SSE 而非 WebSocket 的核心考量：LLM 推理是服务端到客户端的单向数据流
作者：old wang
分类： RAG

RAG 回答链路设计

这条链路是 RAG 的核心——从用户输入到流式回答的全过程。整体耗时预算在 5 到 15 秒（从用户发消息到首字出现），其中 LLM 推理占大头，前面的检索链路需要控制在 1 到 3 秒内完成。 请求进入后先过限流排队拿 LLM 调用许可，然后统一编排 8 个阶段串行推进，但阶段内部有并行和短路设计
作者：old wang
分类： RAG

文档入库链路设计

文档入库是将外部文件（PDF、Word、Markdown、网页等）转化为可检索的向量化文本块的完整流程。入口有两个：管理后台上传 和外部来源（S3、HTTP、飞书文档）。 1. 总体架构 创建任务（事务内） │ ├─ 写入任务记录（t_ingestion_task，状态=RUNNING）
作者：old wang
分类： RAG

文档切分方案

文档切分（Chunking）是 RAG 链路中最直接影响检索质量的环节——切得好，用户问什么都能命中；切得不好，向量检索再准也搜不到。 核心矛盾是：**文本块太大**，语义被稀释，检索时匹配不到精确信息；**文本块太小**，上下文丢失，LLM 拿到碎片化的内容拼不出完整答案。切分策略要在"保持语义完
作者：old wang
分类： RAG

2025 年 05 月

Redis 使用方案

Redis 在 RAG 项目中承担了四类职责：业务缓存、分布式协调、并发控制、跨实例通信。选用 Redisson 作为主力客户端，因为它将 Redis 的数据结构（信号量、ZSET、Topic、分布式锁）封装为 Java 原生对象，不需要手动管理连接池和序列化。简单 KV 场景用 StringRed
作者：old wang
分类： RAG

线程池抛了异常怎么处理？

线程池抛了异常怎么处理？只写 try-catch 还不够 在 Java 项目中，线程池是很常见的异步执行工具。 但线程池里的任务一旦抛出异常，处理方式并没有很多人想得那么简单。 尤其是 execute() 和 submit() 两种提交方式，对异常的处理行为完全不同： execute() 提交的任务
作者：old wang
分类： 性能优化

线程池中如何正确传递 traceId？

为什么 InheritableThreadLocal 在线程池中不可靠？ 在 Java Web 项目中，我们经常会把一些请求级上下文信息放到 ThreadLocal 中，例如： traceId userId tenantId 登录用户信息 日志 MDC 上下文 这样做的好处
作者：old wang
分类： 工程实践

Spring Boot 菜单无限层级设计

parent_id、路径枚举与闭包表怎么选 后台系统里，菜单、部门、分类、权限资源都绕不开树形结构。很多系统一开始都会用 parent_id，因为它简单、直观、好维护。但一旦线上出现递归栈溢出、循环引用、查询变慢，就容易得出一个过度结论parent_id 不行，必须换闭包表。 这个结论并不准确。 树
作者：old wang
分类： 工程实践

用户反馈问答很慢 排查思路

SSE 问答和普通接口不一样，用户感受最明显的是两个时间：一个是 排队等待时间，另一个是 模型首包时间。如果用户 30 秒才看到第一个字，不一定是模型慢，也可能是前面排队太久、检索慢、Rerank 慢、Prompt 太长、线程池打满，或者 SSE 写出阻塞。 第一，看 Redis 等待队列。
作者：old wang
分类： RAG
标签： #问题排查
共 46 篇文章
页