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

Redis 使用方案

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

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

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

知识库文档入库任务系统设计

文档入库不是上传完文件就结束，后面还有解析、分块、Embedding、向量写入、状态更新这些步骤。这里面解析可能失败，Embedding 可能超时，向量库可能写入失败，用户也可能在任务执行中删除文档或取消任务。所以我不会把它做成一个同步接口，而是设计成 上传接口 + 任务状态机 + MQ 异步消费
作者：old wang
分类： RAG

RAG实际应用场景

这是 RAG 最经典的应用场景，几乎每个上了规模的公司都有需求。 员工想查公司的报销制度、请假流程、技术规范，以前要么翻 Wiki 翻半天，要么直接问同事。现在接个 RAG 系统，自然语言问一句就能得到答案，还能告诉你出处在哪个文档。 典型的知识来源包括：公司制度文档、产品手册、技术文档、历史项目沉
作者：old wang
分类： RAG

RAG的几个难点

1. 数据入向量库 企业里的知识不会乖乖地以纯文本形式等着你。PDF、Word、PPT、网页、Markdown、数据库，什么都有。光是把这些东西解析成干净的文本，就是一堆脏活累活。PDF 里的表格、扫描件、双栏排版，每一个都是坑文档要切成小块才能检索，但切多大是个问题。切太大，检索不精准，一大段里可
作者：old wang
分类： RAG
共 13 篇文章
页