项目采用 多路召回 Rerank的RAG架构核心入口是 RagSpecialistAgent.java当用户与问答助手进行语言交流时输入查询首先先进行意图识别判断是单任务还是多任务并且判断是否需要RAG检索因为对于记录热量记账等操作无需进行RAG检索增强只有针对那种用户学校的私有知识才需要走RAG流程。多路召回的具体流程1.向量检索ES KNNk-nearest neighbork 近邻向量搜索给定一个查询向量从索引中找出最相似的Top-K向量文档近似KNN是生产首选采用HNSW算法HNSW是多层图索引把向量组织成多层网络上层稀疏、粗粒度快速过滤候选下层稠密、细粒度精确找近邻搜索从顶层入口 → 逐层往下贪心遍历 → 收集最近邻核心 trade-offm每层每个节点最大连接数默认 16→ 越大越准、越耗内存ef_construction建图时候选队列大小默认 100→ 越大建索引越慢、召回越高private ListMapString, Object knnSearch(String query, String school, int topK) { float[] embedding embeddingModel.embed(query); // 生成向量 // 使用 ES 的 knn 查询 .knn(k - k .field(embedding) .queryVector(queryVector) .k(topK) .numCandidates(topK * 2) ) // 低分过滤score 0.5 }Embedding模型选取的是阿里百炼平台的向量模型会生成1536维向量ES向量检索会采用余弦相似度。2.BM25文本检索关键词检索Best Matching 25ES、Solr 默认经典概率检索打分算法用来做关键词文本相似度匹配检索传统文字内容。词频 TF词语在文档出现次数越多分越高逆文档频率 IDF词越稀有权重越高常用词权重压低文档长度抑制长文档天然占便宜避免越长分越高private ListMapString, Object textSearch(String keyword, String school, int topK) { builder.query(q - q.bool(b - b .must(m - m.match(mc - mc.field(question).query(keyword))) .filter(f - f.term(t - t.field(school).value(school))) )); }3.对双路检索到的结果进行去重使用LinkedHashMapMapString, MapString, Object dedupMap new LinkedHashMap(); // docId school | title String docId getDocId(r); dedupMap.put(docId, r); // 后出现的同ID会被忽略4.Rerank重排序调用 阿里云 DashScope Rerank API qwen3-rerank 模型对多路召回结果进行语义重排。相关问题1为什么是这两种检索方式有没有别的检索方式为什么不用其他的方式还有知识图谱检索 (Knowledge Graph)ColBERT (Late Interaction)等。不选第一个的原因是需要额外构建知识图谱会增加系统的复杂度而且针对学校的私有信息例如奖学金宿舍信息等不会很复杂和困难因此无需使用复杂度较高的检索方式不选第二个的原因是需要特殊的 embedding 模型。2知识库如何进行扩充针对学校的私有知识管理员手动上传文档然后经过数据清洗chunk以及向量化最后存入数据库chunk时会进行少量的重复防止语义断裂针对chunk的切分方式我知道的有以下几种1.固定大小切块基础常用按字符 / Token 固定长度切割设重叠窗口防语义断裂特点实现最简单、速度快适用规整文档、纯文本2. 滑动窗口切块固定步长滑动切割相邻块保留重叠内容特点减少上下文丢失提升召回完整性适用长段落、连续叙事文本3. 语义切块智能最优依据句子语义边界、语义相似度分割不割裂完整含义特点块语义独立完整检索精度最高适用论文、合同、专业资料4. 层级切块先大章节拆分再逐层细分段落、句子树形结构分块特点保留文档层级结构适用书籍、手册、带标题层级文档5. 规则分隔切块按换行、句号、分页符、标题标签、特殊符号切割特点贴合原生排版边界清晰适用PDF、Word、结构化台账6. 标题驱动切块以一级 / 二级标题为分割依据一个标题对应一个块特点主题高度统一适用报告、规章制度、技术文档7. 问答式切块把原文拆成独立问答单元一问一答为单块特点贴合提问检索习惯适用题库、FAQ、客服话术5.向量模型与重排模型的选择应该注意什么问题首先是向量模型选型时需要注意第一领域要匹配业务场景专业场景可以使用微调过的专用模型通用文本使用通用预训练模型保障语义表征贴合业务特征第二维度严格统一模型输出向量维度必须和向量数据库索引维度保持一致避免入库、检索异常第三权衡精度与性能参数量、向量维度越高语义效果越好但资源消耗、推理耗时同步上升根据并发规模、硬件资源合理取舍第四适配相似度算法模型输出格式匹配库内设定的余弦、点积、欧式距离计算规则保证相似度判定有效第五上下文窗口适配切块长度根据文本分块大小选择对应上下文长度的模型防止文本截断丢失关键信息。其次重排模型选型时需要注意第一明确使用定位重排仅作用于检索召回后的候选集不替代全量检索用来精细化筛选排序结果第二把控候选集数量常规选取 20-50 条召回结果送入重排数量过多会大幅增加耗时影响接口响应速度第三匹配文本长度依据分块文本篇幅选择对应窗口大小的重排模型避免超长文本无法完整解析第四按需取舍精度高精准业务选用高精度重排模型高并发吞吐场景选用轻量化模型平衡效率。6.如何评估你的RAG的效果如何向量模型效果评估基础召回指标采用召回率、精确率、F1 分数评判检索匹配度检验相关文档能否被有效筛选出来。相似度分布检验查看同类文本向量距离、异类文本向量距离合格模型同类聚集、异类区分明显。场景实测验证结合业务测试集提问对比真实标准答案判断语义匹配、专业术语识别能力。性能指标评估统计单条推理耗时、内存占用兼顾检索精度与线上并发承载能力。重排模型效果评估排序质量指标使用 NDCG、MAP 评价排序合理性越相关的文档排名越靠前。正负样本区分度测试模型能否有效区分高度相关、弱相关、无关文本过滤无效干扰结果。边界案例测试针对歧义语句、近似语义、专业话术做测试检验排序稳定性。耗时开销评估统计重排处理耗时控制候选集处理时延满足接口响应要求。整体链路综合评估全流程对比打分分别单用 BM25、向量检索、向量加重排组合横向对比最终检索准确率。极端用例验证短句、长文本、模糊语义、专业冷门词汇全覆盖测试鲁棒性。业务落地验收贴合实际业务查询场景以真实使用体验、答案可用性作为最终评判依据。
