首先要申明 这不仅是一个rag系统是一个智能agent系统可以搭载rag。rag系统是其中一个重要的环节。这个版本做的迭代是rag部分的优化。rag系统的优化策略分为三步走事前(如何分块) 事中(如何检索刀有效块) 事后(召回优化)。优化思路技术原理Query2Doc利用 LLM 生成伪文档将查询与伪文档拼接后检索弥补查询信息不足HyDE假设文档嵌入生成假设性答案并嵌入可选与原始查询嵌入取平均用向量检索子问题拆解将复杂问题分解为多个子问题分别检索后回答查询改写生成查询的转述版本增加领域关键词提升召回率Step-Back 提示通过少样本示例将具体问题抽象为更一般性的问题更容易匹配到相关文档Multi-Query多查询生成LLM 从不同角度生成多个查询变体分别检索后取并集去重提升召回率RAG Fusion递归融合检索Multi-Query RRF 倒数排名融合多查询共识的文档排名更高提升排序质量PRF伪相关反馈首轮检索 Top-K 结果中提取关键词扩展查询再检索数据驱动的自举策略语义扩展Embedding Expansion在词向量空间中找查询关键词的近义词/相关词扩展查询无需 LLM速度快上下文查询重构多轮对话中补全指代词和省略信息生成独立可检索的完整查询RaFe排序反馈改写小模型改写查询→检索→评估排序质量→反馈优化形成可学习的改写闭环技术原理Auto-Merging自动合并检索多层树状索引子块命中超阈值自动合并为父块避免零散返回Multi-Vector / ColBERT多向量检索一个文档对应多个 token 级向量迟交互机制做词级精细匹配知识图谱索引提取实体和关系建图通过路径遍历支持多跳推理检索RAPTOR层级递归索引递归聚类摘要构建多层树检索时适配不同抽象层级元数据过滤索引向量索引附加结构化元数据先硬过滤再向量检索精准缩小范围SPLADE稀疏学习索引学习型稀疏向量兼得 BM25 关键词匹配 语义理解能力以下是鄙人的一家之言仅供参考通用型的系统做文档上传-分块-自然语言问题-查询数据给模型-返回结果。工程上优化的再好普适性的也就是60分往上很难说做到所有场景都是90分。最好的rag问答是数据清洗完之后再分块然后将通用性的问答沉淀到FAQ这个才是首选技术角度提升效果有限。不要一个机器人挂不同业务的文档库可以做一个简单的意图识别不同的业务甚至同一个业务不同的模块都可以拆分为一个机器人通过意图识别去路由对应的机器人进行问答。这个是爱码士认为的最优解。以上优化大部分是非技术角度的今天给大家带来技术角度的优化。是事中、事后的优化事前部分的优化下个版本迭代给大家提供一种思路花钱能解决的事情千万别写代码。此次的整体流程升级用户提问后系统经过4 个阶段从知识库中找到最相关的文档片段BM25 向量双路召回 → RRF 融合排名 → CrossEncoder 重排 → 置信度自适应加权出最终结果1️⃣双路并行检索BM25 向量语义检索想象你要在图书馆找一本书有两种查找方式检索方式生活比喻技术原理优势劣势BM25 全文检索按关键词查字典 比如搜苹果找所有包含苹果的文档统计查询词在文档中出现的频率 词频越高越相关✅ 精准匹配关键词 ✅ 速度快❌ 不懂语义 ❌ “苹果手机搜不到iPhone”向量语义检索按意思找朋友 比如你说想吃水果朋友递给你苹果把文字转成向量数字数组 计算相似度余弦相似度✅ 理解语义 ✅ “苹果手机能匹配iPhone”❌ 可能忽略关键词 ❌ 计算慢2️⃣RRF 智能排序融合Reciprocal Rank Fusion问题文档 A 在 BM25 排第 1在向量检索排第 2它应该是总榜第几名 使用RRF算法的目的是将两个榜单合并3️⃣CrossEncoder 高精度重排什么是 CrossEncoder想象你是阅卷老师有两种批改方式模型类型比喻工作原理精度速度BiEncoder向量检索用快速初筛 给每份试卷单独打分分别计算 query 和文档的向量 然后算相似度⭐⭐⭐ 快CrossEncoder重排用精细批改 逐字逐句对比把 query 和文档拼在一起 用注意力机制深度交互⭐⭐⭐⭐⭐ 慢BiEncoder: query → [向量] ↘ 余弦相似度 → 0.85 文档 → [向量] ↗CrossEncoder: [query 文档] → [深度交互] → 分数 0.924️⃣位置感知加权融合这是什么意思根据文档在 RRF 榜单中的排名位置动态调整RRF 分数和重排分数的权重比例。 **完整流程串联 **场景用户搜索苹果手机多少钱Step 1: 双路并行检索BM25 路径关键词匹配 苹果手机价格 → 第 1 名包含完整关键词苹果报价 → 第 2 名包含苹果手机多少钱 → 第 3 名包含手机向量路径语义匹配iPhone 15 售价 → 第 1 名语义等价苹果手机价格 → 第 2 名语义 关键词华为手机报价 → 第 3 名都是手机两路同时跑耗时从 100ms 降到 50msStep 2: RRF 融合文档苹果手机价格 BM25 排名第 1 → RRF 分数 1/(6011) 0.0161 向量排名第 2 → RRF 分数 1/(6021) 0.0159 合计 0.032排总榜第 1 因为是冠军额外奖励 0.05 → 最终 0.082文档iPhone 15 售价 BM25 没进前 10 → 0 分 向量排名第 1 → 1/(6011) 0.0161 合计 0.0161排总榜第 2取 Top30 进入下一轮...Step 3: CrossEncoder 重排对 Top30 逐个精细打分 苹果手机价格 → 原始分 2.5 → sigmoid 后 0.92 → 高度相关 ⭐⭐⭐⭐⭐ iPhone 15 售价 → 原始分 1.8 → sigmoid 后 0.86 → 高度相关 ⭐⭐⭐⭐⭐ 华为手机报价 → 原始分 0.3 → sigmoid 后 0.57 → 中等相关 ⭐⭐⭐Step 4: 位置感知加权Top1 苹果手机价格 RRF 分数0.082重排分0.92 最终分 0.082×0.75 0.92×0.25 0.292Top2 iPhone 15 售价 RRF 分数0.016重排分0.86 最终分 0.016×0.75 0.86×0.25 0.227Top15 苹果官方公告后排逆袭 RRF 分数0.008重排分0.95 最终分 0.008×0.40 0.95×0.60 0.573 ← 直接冲进前 3二、此次升级整体改动2.1 新旧架构对比【旧架构】单路向量检索 Query → Embedding → Milvus Search → TopK → Context【新架构】混合检索流水线 (8 Stages) Query ──┬→ Milvus 向量召回 ──┐ └→ BM25 关键词召回 ──┘→ 合并 → RRF融合 → 归一化 → 重排 → 自适应融合 → 截断 → 组装2.2 新增模块总览src/main/java/com/isy/rag/bootstrap/rag/retrieval/kb/├── assemble/│ └── KbContextAssembler.java # Stage8: 上下文组装器├── blend/│ └── ConfidenceAdaptiveScoreBlender.java # Stage6: 自适应分数融合器├── config/│ ├── ElasticsearchConfig.java # ES 客户端配置│ └── KbRetrievalProperties.java # 混合检索配置项 (rag.kb.hybrid.*)├── cutoff/│ └── KbResultCutoff.java # Stage7: TopK 阈值双重截断器├── es/│ └── KbEsIndexService.java # ES 索引服务 (BM25 IK分词)├── fusion/│ ├── KbRrfFusion.java # Stage3: RRF 融合器│ └── ScoreNormalizer.java # Stage4: Min-Max 归一化器├── merge/│ └── KbCandidateMerger.java # Stage2: 同chunk候选合并器├── model/│ ├── KbCandidate.java # 候选统一模型 (6类分数)│ ├── KbCandidateSource.java # 命中来源枚举 (VECTOR/BM25/BOTH)│ ├── KbRetrievalRequest.java # 检索请求 (含effective默认值)│ ├── KbRetrievalResult.java # 检索结果 (含阶段耗时统计)│ └── RelevanceLevel.java # 相关性等级枚举├── pipeline/│ └── KbHybridRetrievalPipeline.java # 8阶段流水线编排器├── rerank/│ ├── KbReranker.java # 重排器接口│ ├── KbRerankerConfig.java # 重排器 Spring 配置 (条件注入)│ ├── NoopKbReranker.java # 空实现降级│ └── RemoteKbReranker.java # 远程 CrossEncoder 重排└── retriever/ ├── KbRetriever.java # 召回器接口 ├── KbBm25Retriever.java # BM25 召回 (ES/MySQL双后端) └── KbVectorRetriever.java # 向量召回 (Milvus)三、8 阶段流水线详细设计Stage 1: 并行混合召回设计思路向量语义召回 BM25 关键词召回并行执行互不阻塞实现要点使用CompletableFuture 固定2线程池并行执行异常隔离单路失败不影响另一路记录 warning 继续流程向量召回通过EmbeddingModel生成查询向量 → Milvus ANN 检索 → 赋 vectorRankBM25 召回支持双后端elasticsearch/mysql通过配置切换ES 后端增量同步 chunk → ES BM25 IK 分词适合生产环境MySQL 后端全量加载 chunk → 内存计算 BM25适合开发/测试关键代码KbVectorRetriever.retrieve()— 向量召回KbBm25Retriever.retrieve()— BM25 召回ES 失败自动降级到 MySQLStage 2: 同 Chunk 候选合并设计思路同一 chunk 被两路同时召回时保留双路所有分数信息实现要点按chunkId合并KbCandidateMerger.mergeAll()处理多列表合并合并时使用coalesce策略优先使用已有数据合并后自动更新matchedBy字段VECTOR/BM25/BOTH双路命中的 chunk 在后续 RRF 融合中将获得更高分数Stage 3: RRF 融合设计思路基于排名的融合 (Reciprocal Rank Fusion)公平合并不同检索器的结果公式rrfScore(d) Σ weight_i × (1 / (k rank_i) bonus(rank_i))创新点 — bonus 融入公式传统 RRF 只用1/(krank)本方案将 rank1/rank2-3 奖励直接融入公式避免了先排序 → 加分 → 再排序的二次排序问题默认参数rrfK60,vectorWeight0.7,bm25Weight0.3,rank1Bonus0.05,rank2To3Bonus0.02为什么用 RRF 而非直接加权融合向量分数范围[0, 1]BM25 分数范围[0, ∞)量纲完全不同RRF 基于排名计算天然消除了分数量纲不一致的问题Stage 4: RRF 分数归一化设计思路将 RRF 原始分数映射到[0, 1]为后续与 rerank 分数融合做准备公式normalizedRrf (rrfScore - minRrf) / (maxRrf - minRrf)边界处理所有分数相等时统一设为1.0rrfScore为 null 的候选跳过归一化Stage 5: CrossEncoder 重排设计思路对候选进行 query-document 对的语义精排弥补检索阶段只看单路的不足实现要点远程重排调用bge-rerankerFastAPI 服务Python 端已做 Sigmoid 归一化Spring 条件注入配置了reranker-url时创建RemoteKbReranker否则NoopKbReranker降级策略远程调用失败时自动降级使用normalizedRrfScore作为rerankScore重排后为每个候选设置RelevanceLevel高度相关(≥0.8) / 中等相关(≥0.5) / 一般相关(≥0.2) / 低相关(0.2)Stage 6: 自适应分数融合设计思路替代固定位置权重根据 CrossEncoder 的置信度动态调整融合权重核心洞察Sigmoid 输出0.5表示模型最不确定离0.5越远模型越自信应赋予更高权重公式certainty 2 × |rerankScore - 0.5|rerankerWeight baseRerankerWeight certainty × adaptiveFactorrerankerWeight clamp(rerankerWeight, minRerankerWeight, maxRerankerWeight)finalScore normalizedRrfScore × (1 - rerankerWeight) rerankScore × rerankerWeight默认参数baseRerankerWeight0.35,adaptiveFactor0.35,min0.30,max0.75效果当重排模型高度自信时score 接近 0 或 1重排权重最高可达 0.75当重排模型不确定时score 接近 0.5重排权重最低降到 0.30更多依赖检索分数Stage 7: TopK 阈值双重截断设计思路双重防线过滤低质量分块防止噪声进入 LLM 上下文过滤条件按顺序finalScore finalScoreThreshold默认 0.45rerankScore rerankThreshold默认 0.55无 rerankScore 时跳过数量不超过maxChunksStage 8: 上下文组装设计思路将最终候选组装为 LLM 可消费的上下文 前端可展示的引用信息实现要点chunkId 去重防止重复按finalScore降序排列上下文格式【文档Nxxx.pdf | chunk3 | score0.82】\n内容\n最大字符数限制默认 8000引用信息携带完整分数字段vector_score,bm25_score,rrf_score,normalized_rrf_score,rerank_score,final_score,relevance_level,matched_by四、数据模型设计4.1 KbCandidate — 候选统一模型一个KbCandidate在流水线中流转逐阶段积累分数Stage1: chunkId, docId, docName, content, vectorScore, vectorRank, bm25Score, bm25Rank, matchedByStage2: (合并后) matchedBy 更新为 BOTHStage3: rrfScoreStage4: normalizedRrfScoreStage5: rerankRawScore, rerankScore, relevanceLevelStage6: finalScore6 类分数的生命周期分数产生阶段范围用途vectorScoreStage1[0, 1]向量相似度原始分bm25ScoreStage1[0, ∞)BM25 原始分rrfScoreStage3(0, 0.1]RRF 融合原始分normalizedRrfScoreStage4[0, 1]RRF 归一化分rerankScoreStage5[0, 1]CrossEncoder 重排分finalScoreStage6[0, 1]最终融合分排序/截断依据4.2 KbCandidateSource — 命中来源枚举值含义前端标签样式VECTOR仅向量命中向量召回蓝色BM25仅关键词命中关键词召回橙色BOTH双路同时命中双路命中紫色4.3 RelevanceLevel — 相关性等级等级分数范围是否纳入前端标签HIGHLY_RELEVANT≥ 0.8是高度相关 (绿)MODERATELY_RELEVANT≥ 0.5是中等相关 (蓝)SOMEWHAT_RELEVANT≥ 0.2否一般相关 (黄)LOW_RELEVANCE 0.2否低相关 (红)五、配置体系设计5.1 application.yml 配置rag: kb: hybrid: enabled:true # 混合检索开关 vector-top-k:30 # 向量召回数 bm25-top-k:30 # BM25 召回数 bm25-backend:elasticsearch# BM25 后端 (elasticsearch / mysql) rrf-top-n:30 # RRF 融合保留数 rrf-k:60 # RRF 常数 k vector-weight:0.7 # 向量权重 bm25-weight:0.3 # BM25 权重 rank1-bonus:0.05 # Rank1 奖励 rank2-to3-bonus:0.02 # Rank2-3 奖励 rerank-enabled:true # 重排开关 reranker-url:http://localhost:8100/rerank# 重排服务地址 rerank-top-n:30 # 重排候选数 rerank-threshold:0.55 # 重排分数阈值 final-score-threshold:0.45# 最终分数阈值 base-reranker-weight:0.35# 基础重排权重 adaptive-factor:0.35 # 自适应因子 min-reranker-weight:0.30# 最小重排权重 max-reranker-weight:0.75# 最大重排权重5.2 降级策略外部服务配置调整降级行为Milvus 不可用—向量召回返回空列表BM25 单路工作ES 不可用bm25-backend: mysql自动降级到 MySQL 内存 BM25Reranker 不可用注释reranker-urlNoopKbReranker生效用归一化 RRF 分数代替全部不可用hybrid.enabled: false回退到传统纯向量检索六、前端展示增强6.1 引用卡片增强每个文档引用卡片新增命中来源标签向量召回/关键词召回/双路命中彩色标签相关性等级高度相关/中等相关/一般相关/低相关分级标签最终分数显示finalScore数值分数详情展开显示完整分数链向量分 → BM25分 → RRF分 → 重排分 → 最终分6.2 管理后台 Bot 配置增强Bot 配置页面新增混合检索配置项展示追踪详情页新增KB_RETRIEVE节点的检索模式标识七、可观测性设计7.1 统一日志标识全链路使用[KB检索]前缀支持grep [KB检索]一键过滤日志标识打印内容[KB检索][入口]query, kbIds, maxChunks[KB检索][模式选择]hybridEnabled, bm25Backend, 选择模式[KB检索][Stage1-向量召回]召回数, topK, Top3 chunkIdvecScoredocName[KB检索][Stage1-BM25召回]召回数, topK, backend, Top3 chunkIdbm25ScoredocName[KB检索][Stage2-候选合并]合并后数, 双路/仅向量/仅BM25 统计[KB检索][Stage3-RRF融合]输入/输出数, rrfK, weights, Top3 rrfScorematchedBy[KB检索][Stage4-分数归一化]候选数, 归一化分数范围 [min, max][KB检索][Stage5-重排]reranker名称, 候选数, Top3 rerankScorelevel[KB检索][Stage6-自适应融合]候选数, weights, Top3 normRrfrerankfinal[KB检索][Stage7-截断]输入/输出/截断数, 阈值, 逐条最终候选摘要[KB检索][Stage8-上下文组装]候选数, 引用数, 字符数[KB检索][总出口]mode, confidence, chunkCount, duration[KB检索][出口]confidence, refCount, contextLen, duration7.2 链路追踪每个 Stage 的耗时通过KbRetrievalResult.recordStageDuration()记录通过TraceEventPublisher发布到追踪系统在管理后台的追踪详情页可查看。八、新增依赖!-- Elasticsearch Java Client --dependency groupIdco.elastic.clients/groupId artifactIdelasticsearch-java/artifactId version8.15.0/version/dependencydependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId/dependencydependency groupIdjakarta.json/groupId artifactIdjakarta.json-api/artifactId version2.1.3/version/dependency学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
企业级开源智能体系统 RAG优化升级
发布时间：2026/6/1 4:08:14
首先要申明 这不仅是一个rag系统是一个智能agent系统可以搭载rag。rag系统是其中一个重要的环节。这个版本做的迭代是rag部分的优化。rag系统的优化策略分为三步走事前(如何分块) 事中(如何检索刀有效块) 事后(召回优化)。优化思路技术原理Query2Doc利用 LLM 生成伪文档将查询与伪文档拼接后检索弥补查询信息不足HyDE假设文档嵌入生成假设性答案并嵌入可选与原始查询嵌入取平均用向量检索子问题拆解将复杂问题分解为多个子问题分别检索后回答查询改写生成查询的转述版本增加领域关键词提升召回率Step-Back 提示通过少样本示例将具体问题抽象为更一般性的问题更容易匹配到相关文档Multi-Query多查询生成LLM 从不同角度生成多个查询变体分别检索后取并集去重提升召回率RAG Fusion递归融合检索Multi-Query RRF 倒数排名融合多查询共识的文档排名更高提升排序质量PRF伪相关反馈首轮检索 Top-K 结果中提取关键词扩展查询再检索数据驱动的自举策略语义扩展Embedding Expansion在词向量空间中找查询关键词的近义词/相关词扩展查询无需 LLM速度快上下文查询重构多轮对话中补全指代词和省略信息生成独立可检索的完整查询RaFe排序反馈改写小模型改写查询→检索→评估排序质量→反馈优化形成可学习的改写闭环技术原理Auto-Merging自动合并检索多层树状索引子块命中超阈值自动合并为父块避免零散返回Multi-Vector / ColBERT多向量检索一个文档对应多个 token 级向量迟交互机制做词级精细匹配知识图谱索引提取实体和关系建图通过路径遍历支持多跳推理检索RAPTOR层级递归索引递归聚类摘要构建多层树检索时适配不同抽象层级元数据过滤索引向量索引附加结构化元数据先硬过滤再向量检索精准缩小范围SPLADE稀疏学习索引学习型稀疏向量兼得 BM25 关键词匹配 语义理解能力以下是鄙人的一家之言仅供参考通用型的系统做文档上传-分块-自然语言问题-查询数据给模型-返回结果。工程上优化的再好普适性的也就是60分往上很难说做到所有场景都是90分。最好的rag问答是数据清洗完之后再分块然后将通用性的问答沉淀到FAQ这个才是首选技术角度提升效果有限。不要一个机器人挂不同业务的文档库可以做一个简单的意图识别不同的业务甚至同一个业务不同的模块都可以拆分为一个机器人通过意图识别去路由对应的机器人进行问答。这个是爱码士认为的最优解。以上优化大部分是非技术角度的今天给大家带来技术角度的优化。是事中、事后的优化事前部分的优化下个版本迭代给大家提供一种思路花钱能解决的事情千万别写代码。此次的整体流程升级用户提问后系统经过4 个阶段从知识库中找到最相关的文档片段BM25 向量双路召回 → RRF 融合排名 → CrossEncoder 重排 → 置信度自适应加权出最终结果1️⃣双路并行检索BM25 向量语义检索想象你要在图书馆找一本书有两种查找方式检索方式生活比喻技术原理优势劣势BM25 全文检索按关键词查字典 比如搜苹果找所有包含苹果的文档统计查询词在文档中出现的频率 词频越高越相关✅ 精准匹配关键词 ✅ 速度快❌ 不懂语义 ❌ “苹果手机搜不到iPhone”向量语义检索按意思找朋友 比如你说想吃水果朋友递给你苹果把文字转成向量数字数组 计算相似度余弦相似度✅ 理解语义 ✅ “苹果手机能匹配iPhone”❌ 可能忽略关键词 ❌ 计算慢2️⃣RRF 智能排序融合Reciprocal Rank Fusion问题文档 A 在 BM25 排第 1在向量检索排第 2它应该是总榜第几名 使用RRF算法的目的是将两个榜单合并3️⃣CrossEncoder 高精度重排什么是 CrossEncoder想象你是阅卷老师有两种批改方式模型类型比喻工作原理精度速度BiEncoder向量检索用快速初筛 给每份试卷单独打分分别计算 query 和文档的向量 然后算相似度⭐⭐⭐ 快CrossEncoder重排用精细批改 逐字逐句对比把 query 和文档拼在一起 用注意力机制深度交互⭐⭐⭐⭐⭐ 慢BiEncoder: query → [向量] ↘ 余弦相似度 → 0.85 文档 → [向量] ↗CrossEncoder: [query 文档] → [深度交互] → 分数 0.924️⃣位置感知加权融合这是什么意思根据文档在 RRF 榜单中的排名位置动态调整RRF 分数和重排分数的权重比例。 **完整流程串联 **场景用户搜索苹果手机多少钱Step 1: 双路并行检索BM25 路径关键词匹配 苹果手机价格 → 第 1 名包含完整关键词苹果报价 → 第 2 名包含苹果手机多少钱 → 第 3 名包含手机向量路径语义匹配iPhone 15 售价 → 第 1 名语义等价苹果手机价格 → 第 2 名语义 关键词华为手机报价 → 第 3 名都是手机两路同时跑耗时从 100ms 降到 50msStep 2: RRF 融合文档苹果手机价格 BM25 排名第 1 → RRF 分数 1/(6011) 0.0161 向量排名第 2 → RRF 分数 1/(6021) 0.0159 合计 0.032排总榜第 1 因为是冠军额外奖励 0.05 → 最终 0.082文档iPhone 15 售价 BM25 没进前 10 → 0 分 向量排名第 1 → 1/(6011) 0.0161 合计 0.0161排总榜第 2取 Top30 进入下一轮...Step 3: CrossEncoder 重排对 Top30 逐个精细打分 苹果手机价格 → 原始分 2.5 → sigmoid 后 0.92 → 高度相关 ⭐⭐⭐⭐⭐ iPhone 15 售价 → 原始分 1.8 → sigmoid 后 0.86 → 高度相关 ⭐⭐⭐⭐⭐ 华为手机报价 → 原始分 0.3 → sigmoid 后 0.57 → 中等相关 ⭐⭐⭐Step 4: 位置感知加权Top1 苹果手机价格 RRF 分数0.082重排分0.92 最终分 0.082×0.75 0.92×0.25 0.292Top2 iPhone 15 售价 RRF 分数0.016重排分0.86 最终分 0.016×0.75 0.86×0.25 0.227Top15 苹果官方公告后排逆袭 RRF 分数0.008重排分0.95 最终分 0.008×0.40 0.95×0.60 0.573 ← 直接冲进前 3二、此次升级整体改动2.1 新旧架构对比【旧架构】单路向量检索 Query → Embedding → Milvus Search → TopK → Context【新架构】混合检索流水线 (8 Stages) Query ──┬→ Milvus 向量召回 ──┐ └→ BM25 关键词召回 ──┘→ 合并 → RRF融合 → 归一化 → 重排 → 自适应融合 → 截断 → 组装2.2 新增模块总览src/main/java/com/isy/rag/bootstrap/rag/retrieval/kb/├── assemble/│ └── KbContextAssembler.java # Stage8: 上下文组装器├── blend/│ └── ConfidenceAdaptiveScoreBlender.java # Stage6: 自适应分数融合器├── config/│ ├── ElasticsearchConfig.java # ES 客户端配置│ └── KbRetrievalProperties.java # 混合检索配置项 (rag.kb.hybrid.*)├── cutoff/│ └── KbResultCutoff.java # Stage7: TopK 阈值双重截断器├── es/│ └── KbEsIndexService.java # ES 索引服务 (BM25 IK分词)├── fusion/│ ├── KbRrfFusion.java # Stage3: RRF 融合器│ └── ScoreNormalizer.java # Stage4: Min-Max 归一化器├── merge/│ └── KbCandidateMerger.java # Stage2: 同chunk候选合并器├── model/│ ├── KbCandidate.java # 候选统一模型 (6类分数)│ ├── KbCandidateSource.java # 命中来源枚举 (VECTOR/BM25/BOTH)│ ├── KbRetrievalRequest.java # 检索请求 (含effective默认值)│ ├── KbRetrievalResult.java # 检索结果 (含阶段耗时统计)│ └── RelevanceLevel.java # 相关性等级枚举├── pipeline/│ └── KbHybridRetrievalPipeline.java # 8阶段流水线编排器├── rerank/│ ├── KbReranker.java # 重排器接口│ ├── KbRerankerConfig.java # 重排器 Spring 配置 (条件注入)│ ├── NoopKbReranker.java # 空实现降级│ └── RemoteKbReranker.java # 远程 CrossEncoder 重排└── retriever/ ├── KbRetriever.java # 召回器接口 ├── KbBm25Retriever.java # BM25 召回 (ES/MySQL双后端) └── KbVectorRetriever.java # 向量召回 (Milvus)三、8 阶段流水线详细设计Stage 1: 并行混合召回设计思路向量语义召回 BM25 关键词召回并行执行互不阻塞实现要点使用CompletableFuture 固定2线程池并行执行异常隔离单路失败不影响另一路记录 warning 继续流程向量召回通过EmbeddingModel生成查询向量 → Milvus ANN 检索 → 赋 vectorRankBM25 召回支持双后端elasticsearch/mysql通过配置切换ES 后端增量同步 chunk → ES BM25 IK 分词适合生产环境MySQL 后端全量加载 chunk → 内存计算 BM25适合开发/测试关键代码KbVectorRetriever.retrieve()— 向量召回KbBm25Retriever.retrieve()— BM25 召回ES 失败自动降级到 MySQLStage 2: 同 Chunk 候选合并设计思路同一 chunk 被两路同时召回时保留双路所有分数信息实现要点按chunkId合并KbCandidateMerger.mergeAll()处理多列表合并合并时使用coalesce策略优先使用已有数据合并后自动更新matchedBy字段VECTOR/BM25/BOTH双路命中的 chunk 在后续 RRF 融合中将获得更高分数Stage 3: RRF 融合设计思路基于排名的融合 (Reciprocal Rank Fusion)公平合并不同检索器的结果公式rrfScore(d) Σ weight_i × (1 / (k rank_i) bonus(rank_i))创新点 — bonus 融入公式传统 RRF 只用1/(krank)本方案将 rank1/rank2-3 奖励直接融入公式避免了先排序 → 加分 → 再排序的二次排序问题默认参数rrfK60,vectorWeight0.7,bm25Weight0.3,rank1Bonus0.05,rank2To3Bonus0.02为什么用 RRF 而非直接加权融合向量分数范围[0, 1]BM25 分数范围[0, ∞)量纲完全不同RRF 基于排名计算天然消除了分数量纲不一致的问题Stage 4: RRF 分数归一化设计思路将 RRF 原始分数映射到[0, 1]为后续与 rerank 分数融合做准备公式normalizedRrf (rrfScore - minRrf) / (maxRrf - minRrf)边界处理所有分数相等时统一设为1.0rrfScore为 null 的候选跳过归一化Stage 5: CrossEncoder 重排设计思路对候选进行 query-document 对的语义精排弥补检索阶段只看单路的不足实现要点远程重排调用bge-rerankerFastAPI 服务Python 端已做 Sigmoid 归一化Spring 条件注入配置了reranker-url时创建RemoteKbReranker否则NoopKbReranker降级策略远程调用失败时自动降级使用normalizedRrfScore作为rerankScore重排后为每个候选设置RelevanceLevel高度相关(≥0.8) / 中等相关(≥0.5) / 一般相关(≥0.2) / 低相关(0.2)Stage 6: 自适应分数融合设计思路替代固定位置权重根据 CrossEncoder 的置信度动态调整融合权重核心洞察Sigmoid 输出0.5表示模型最不确定离0.5越远模型越自信应赋予更高权重公式certainty 2 × |rerankScore - 0.5|rerankerWeight baseRerankerWeight certainty × adaptiveFactorrerankerWeight clamp(rerankerWeight, minRerankerWeight, maxRerankerWeight)finalScore normalizedRrfScore × (1 - rerankerWeight) rerankScore × rerankerWeight默认参数baseRerankerWeight0.35,adaptiveFactor0.35,min0.30,max0.75效果当重排模型高度自信时score 接近 0 或 1重排权重最高可达 0.75当重排模型不确定时score 接近 0.5重排权重最低降到 0.30更多依赖检索分数Stage 7: TopK 阈值双重截断设计思路双重防线过滤低质量分块防止噪声进入 LLM 上下文过滤条件按顺序finalScore finalScoreThreshold默认 0.45rerankScore rerankThreshold默认 0.55无 rerankScore 时跳过数量不超过maxChunksStage 8: 上下文组装设计思路将最终候选组装为 LLM 可消费的上下文 前端可展示的引用信息实现要点chunkId 去重防止重复按finalScore降序排列上下文格式【文档Nxxx.pdf | chunk3 | score0.82】\n内容\n最大字符数限制默认 8000引用信息携带完整分数字段vector_score,bm25_score,rrf_score,normalized_rrf_score,rerank_score,final_score,relevance_level,matched_by四、数据模型设计4.1 KbCandidate — 候选统一模型一个KbCandidate在流水线中流转逐阶段积累分数Stage1: chunkId, docId, docName, content, vectorScore, vectorRank, bm25Score, bm25Rank, matchedByStage2: (合并后) matchedBy 更新为 BOTHStage3: rrfScoreStage4: normalizedRrfScoreStage5: rerankRawScore, rerankScore, relevanceLevelStage6: finalScore6 类分数的生命周期分数产生阶段范围用途vectorScoreStage1[0, 1]向量相似度原始分bm25ScoreStage1[0, ∞)BM25 原始分rrfScoreStage3(0, 0.1]RRF 融合原始分normalizedRrfScoreStage4[0, 1]RRF 归一化分rerankScoreStage5[0, 1]CrossEncoder 重排分finalScoreStage6[0, 1]最终融合分排序/截断依据4.2 KbCandidateSource — 命中来源枚举值含义前端标签样式VECTOR仅向量命中向量召回蓝色BM25仅关键词命中关键词召回橙色BOTH双路同时命中双路命中紫色4.3 RelevanceLevel — 相关性等级等级分数范围是否纳入前端标签HIGHLY_RELEVANT≥ 0.8是高度相关 (绿)MODERATELY_RELEVANT≥ 0.5是中等相关 (蓝)SOMEWHAT_RELEVANT≥ 0.2否一般相关 (黄)LOW_RELEVANCE 0.2否低相关 (红)五、配置体系设计5.1 application.yml 配置rag: kb: hybrid: enabled:true # 混合检索开关 vector-top-k:30 # 向量召回数 bm25-top-k:30 # BM25 召回数 bm25-backend:elasticsearch# BM25 后端 (elasticsearch / mysql) rrf-top-n:30 # RRF 融合保留数 rrf-k:60 # RRF 常数 k vector-weight:0.7 # 向量权重 bm25-weight:0.3 # BM25 权重 rank1-bonus:0.05 # Rank1 奖励 rank2-to3-bonus:0.02 # Rank2-3 奖励 rerank-enabled:true # 重排开关 reranker-url:http://localhost:8100/rerank# 重排服务地址 rerank-top-n:30 # 重排候选数 rerank-threshold:0.55 # 重排分数阈值 final-score-threshold:0.45# 最终分数阈值 base-reranker-weight:0.35# 基础重排权重 adaptive-factor:0.35 # 自适应因子 min-reranker-weight:0.30# 最小重排权重 max-reranker-weight:0.75# 最大重排权重5.2 降级策略外部服务配置调整降级行为Milvus 不可用—向量召回返回空列表BM25 单路工作ES 不可用bm25-backend: mysql自动降级到 MySQL 内存 BM25Reranker 不可用注释reranker-urlNoopKbReranker生效用归一化 RRF 分数代替全部不可用hybrid.enabled: false回退到传统纯向量检索六、前端展示增强6.1 引用卡片增强每个文档引用卡片新增命中来源标签向量召回/关键词召回/双路命中彩色标签相关性等级高度相关/中等相关/一般相关/低相关分级标签最终分数显示finalScore数值分数详情展开显示完整分数链向量分 → BM25分 → RRF分 → 重排分 → 最终分6.2 管理后台 Bot 配置增强Bot 配置页面新增混合检索配置项展示追踪详情页新增KB_RETRIEVE节点的检索模式标识七、可观测性设计7.1 统一日志标识全链路使用[KB检索]前缀支持grep [KB检索]一键过滤日志标识打印内容[KB检索][入口]query, kbIds, maxChunks[KB检索][模式选择]hybridEnabled, bm25Backend, 选择模式[KB检索][Stage1-向量召回]召回数, topK, Top3 chunkIdvecScoredocName[KB检索][Stage1-BM25召回]召回数, topK, backend, Top3 chunkIdbm25ScoredocName[KB检索][Stage2-候选合并]合并后数, 双路/仅向量/仅BM25 统计[KB检索][Stage3-RRF融合]输入/输出数, rrfK, weights, Top3 rrfScorematchedBy[KB检索][Stage4-分数归一化]候选数, 归一化分数范围 [min, max][KB检索][Stage5-重排]reranker名称, 候选数, Top3 rerankScorelevel[KB检索][Stage6-自适应融合]候选数, weights, Top3 normRrfrerankfinal[KB检索][Stage7-截断]输入/输出/截断数, 阈值, 逐条最终候选摘要[KB检索][Stage8-上下文组装]候选数, 引用数, 字符数[KB检索][总出口]mode, confidence, chunkCount, duration[KB检索][出口]confidence, refCount, contextLen, duration7.2 链路追踪每个 Stage 的耗时通过KbRetrievalResult.recordStageDuration()记录通过TraceEventPublisher发布到追踪系统在管理后台的追踪详情页可查看。八、新增依赖!-- Elasticsearch Java Client --dependency groupIdco.elastic.clients/groupId artifactIdelasticsearch-java/artifactId version8.15.0/version/dependencydependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId/dependencydependency groupIdjakarta.json/groupId artifactIdjakarta.json-api/artifactId version2.1.3/version/dependency学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
相关文章
避坑指南：Node-RED处理Modbus-RTU负温度补码与数据解析的完整流程
Node-RED实战：Modbus-RTU负温度补码解析与数据处理的深度剖析在工业物联网和自动化控制领域，Modbus协议因其简单可靠而广受欢迎，但协议中负数的补码表示方式常常成为开发者数据解析路上的"绊脚石"。我曾在一个冷链监控项目中&#…
Spring Boot项目引入自家SDK JAR包踩坑记：从恼人的打包警告到优雅的依赖管理方案
Spring Boot项目依赖管理进阶：从本地JAR引入到私有仓库搭建全指南第一次在Spring Boot项目中引入公司内部SDK时，那种"跑通Demo"的兴奋感很快被一连串打包警告浇灭。作为从个人开发转向团队协作的必经之路，依赖管理规范化是每个Java…
从支配树到泄漏点：图解MAT内存泄漏检测原理，帮你真正看懂‘可疑对象’报告
从支配树到泄漏点：图解MAT内存泄漏检测原理，帮你真正看懂‘可疑对象’报告 当Java应用出现内存泄漏时，开发者往往面临一个尴尬局面：明明MAT工具已经给出了"Leak Suspects"报告，却依然无法准确判断问题根源。…
企业直播缺主播？2026十大AI数字人直播系统实现全天候在线
帮助中小企业摆脱直播的人力束缚、实现全天候自动播，正是当下AI数字人直播系统最核心的解决方向。2026年一季度，京东平台头部商家的数字人开播率已达80%，开播量同比激增10倍。对于缺乏专业直播团队的众多中小企业，人手不够、成本过…
镀锌与金属波纹管价格趋势及生产厂家分析
本文将对镀锌与金属波纹管的价格趋势及其主要生产厂家进行概述。由于原材料的价格波动，镀锌金属波纹管在市场上的价格近期有所变化，预计2026年将保持相对稳定。同时，矩形波纹管的市场价格受到需求及生产成本的影响、存在一定的差异。主要生产…
libcurl 不止于HTTP：一个C++程序员的实战笔记，用libcurl轻松玩转FTP文件上传和SMTP邮件发送
libcurl 不止于HTTP：一个C程序员的实战笔记，用libcurl轻松玩转FTP文件上传和SMTP邮件发送如果你已经成功编译了libcurl，并且熟悉了基础的HTTP请求操作，那么是时候探索这个"网络瑞士军刀"更强大的功能了。libcurl之所以在…
超越fsck -y：深入理解Ubuntu救援模式下的fsck命令选项与安全修复策略
超越fsck -y：Ubuntu救援模式下的磁盘修复艺术与风险控制当Ubuntu系统突然拒绝启动，屏幕上跳出"emergency mode"的红色警告时，大多数管理员的第一反应是本能地输入fsck -y——这个看似万能的修复命令就像医疗急救中的肾上腺素&#…
无人机避障规划实战：如何用ESDF地图让Fast-Planner飞得更安全？
无人机避障规划实战：ESDF地图如何赋能Fast-Planner实现毫米级安全飞行当一架四旋翼以8米/秒的速度穿越密集竹林时，传统栅格地图可能让它在最后0.2秒才检测到前方障碍。而采用ESDF（欧式符号距离场）的Fast-Planner，早在3…
5个步骤快速解锁WeMod完整功能：Wand-Enhancer终极指南
5个步骤快速解锁WeMod完整功能：Wand-Enhancer终极指南 【免费下载链接】Wand-Enhancer Advanced UX and interoperability extension for Wand (WeMod) app 项目地址: https://gitcode.com/gh_mirrors/we/Wand-Enhancer 想要免费体验WeMod专业版的所有高级功…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…
Win10/Win11下Realtek 8188GU网卡驱动感叹号？别急着扔，试试这个手动安装的野路子
Realtek 8188GU网卡驱动故障深度修复指南：从原理到实战当设备管理器里那个顽固的黄色感叹号挥之不去，而你已经尝试了所有"标准操作"——Windows自动更新、第三方驱动工具、甚至重启大法——却依然无济于事时，是时候换个思路了。这篇…
AnolisOS 8.8安装源配置踩坑实录：从‘设置基础软件仓库时出错’到成功联网的保姆级指南
AnolisOS 8.8安装源配置实战指南：从诊断到解决方案的全流程解析当你在安装AnolisOS 8.8时遇到"设置基础软件仓库时出错"的提示，这通常意味着系统无法访问或识别安装源。这个问题看似简单，但背后可能涉及网络配置、镜像选择、启动参…
基于树莓派Pico的反应速度测试游戏：从GPIO编程到状态机实战
1. 项目概述与核心思路最近在整理工作室的电子元件，翻出来几个闲置的街机按钮和一块树莓派Pico，灵机一动，决定做个简单又有趣的反应速度测试游戏。这个项目非常适合想入门嵌入式开发的朋友，它不涉及复杂的传感器和通信协议&#x…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…