尧图网站建设 
简介阿里云AI搜索RAG大模型优化实践PDF文档面向AI搜索、大模型应用与知识问答方向的算法工程师和技术决策者系统讲解RAG模型在文档解析、语义切片、信息召回、检索服务及大模型微调等关键环节的优化方法。资源为单个PDF文件大小17.76MB内容基于阿里云AI搜索团队的落地经验涵盖RAG架构全景、语义层级抽取模型、数据增强与模型训练、混合索引与重排、效果评测体系以及Agent与微调探索等实践模块。已有351人学习浏览适合在复杂文档场景中提升问答准确性、降低幻觉率并实现可溯源回答的读者参考。通过学习可掌握从文档结构化、切片语义补全到检索增强生成的可复用流程理解Qwen系列模型微调与Model-as-Judge评测工作流的应用技巧。1. 阿里云 AI 搜索 RAG 优化实践为什么你的检索总在浪费大模型算力我见过不少团队在阿里云 AI 搜索 RAG 项目上连续加班三周上线后用户问“为什么不能退款”模型却回复“请联系客服”而知识库里明明躺着完整的自助退款流程。问题通常不在大模型而在检索链路索引切得太粗、TOP-K 设得太小、重排序被当成口号。这份《阿里云 AI 搜索 RAG 大模型优化实践》PDF 讲的就是把“答非所问”修好的具体方法从切片参数、混合检索到重排序和离线评估一整套都能直接抄。适合已经跑通 demo、正被召回率和幻觉困扰的工程师也适合准备在阿里云上搭建知识库问答、想少走弯路的团队。2. 第一套阿里云 RAG 工作流组件选型与数据流转2.1 先分清三类“库”RAG 知识库、结构知识库与知识图谱很多人把 RAG 的瓶颈归结为大模型不行其实第一步就错了数据源被一股脑塞进同一个库。先把“库”的类型分清楚后面所有调参才有意义。RAG 知识库面向非结构化文本适合回答“这份合同里违约金怎么写的”“这个政策文件原文怎么说”。结构知识库面向表格、维表和可查询的数据库适合回答“某个型号的单价是多少”“这个订单处在什么状态”。知识图谱则面向实体关系适合多跳问题比如“哪些设备型号支持 5G 且具备 IP68 防水”。在阿里云环境里这三类数据经常混着来。但把订单表硬导进 RAG 知识库就成了一场灾难表格被拆成“列名 值”的碎片语义全断检索回来的段落像乱码。常见的做法是文档、公告、帮助中心文章进 RAG 知识库查状态、查数值、需要聚合的走 API 或结构化表多跳分析才考虑图谱。另外补充一个高频问题RAG 知识库能不能存图片能但前提是想清楚被检索的是图片里的文本还是图片本身。如果业务必须看图回答更可靠的做法是先把图片做内容提取或图生文再把生成的结构化描述送进索引而不是直接让向量模型去匹配一张无标签的 PNG。2.2 数据流转从 OSS 文档到线上索引整套 RAG 链路在阿里云上通常是这样的源文件先进 OSS再由平台做文档解析、切片、向量化最后落成在线索引。这个顺序不能乱因为解析和切片直接决定检索质量而 OSS 是阿里云上最通用的中间存储。上传数据这一步我用 ossutil 批量同步ossutil cp ./data/ oss://example-bucket/rag-docs/ --update --jobs 10 --force这个命令把本地 data 目录同步到 OSS 里。--update只上传本地有而远端没有的增量文件适合每天更新文档--jobs 10控制并发线程数带宽够时能明显加快大批量 PDF 的上传--force跳过交互确认方便在 CI 脚本里跑。传完之后到阿里云 AI 搜索开放平台或百炼控制台创建应用绑定这个 OSS 目录。平台会自动做文档解析和切片。初期建议先用默认的“智能切分”跑通全链路不要一上来就自定义不然你很难判断问题出在切分还是后面的检索。如果你上传的 PDF 大量是扫描件记得确认解析配置里 OCR 已开启。否则索引里全是空白文本后面检索命中率自然趋近于零。2.3 用校验逻辑把“索引不完整”暴露出来数据同步后别急着信控制台上的“已同步”。我每个项目都会跑一遍“三数校验”OSS 里的源文件数、平台上解析完成的文档数、实际切分出的 chunk 数。三者差异过大说明链路有环节静默失败了。import os local_docs [f for f in os.listdir(./data/)] print(f本地源文件: {len(local_docs)}) synced_docs get_platform_docs(app_id) # 替换成对应 SDK 的查询接口 chunks get_platform_chunks(app_id) # 获取索引段统计 print(f平台文档: {len(synced_docs)}, 索引段: {len(chunks)})这里的get_platform_docs和get_platform_chunks是示意函数实际实现要按你用的百炼或 AI 搜索开放平台 OpenAPI 替换。我的习惯是先传 10 份样例文档看切分后的 chunk 数是否在合理范围。一份 20 页的 PDF 正常能切出 80 到 150 个 chunk如果只有 2 个那大概率是解析直接失败了继续调检索参数没有任何意义。2.4 入口选型百炼和 AI 搜索开放平台怎么分工阿里云里做 RAG控制台上通常有两个长得像的入口百炼和 AI 搜索开放平台。我的理解是百炼偏“应用层”内置了模型调用、提示词模板、知识库和插件编排AI 搜索开放平台偏“检索层”把文档解析、向量索引、混合检索、重排序暴露成 OpenAPI你可以只接它的检索结果再喂给自己习惯的大模型。如果团队已有大模型 API或者想深度定制检索链路用 AI 搜索开放平台更顺手如果还在 MVP 阶段直接上百炼因为它已经把知识库和应用串好了开箱即用。更现实的建议是别两套并行。我早期项目就吃过双写的亏数据和权限各维护一套最后谁也不信谁。后来定下规矩检索统一走一个入口应用侧只做封装。3. 索引与切片参数决定召回上限的三套配置3.1 为什么直接整段塞进向量库会“翻车”很多团队图省事按文档原始段落直接 embedding一份 PDF 只有 10 段每段 3000 字。这样生成的向量会把多个主题混在一个向量里用户查询和它的相似度永远不痛不痒最终 TOP-K 里全是不沾边的结果。这不是大模型问题是检索输入的粒度错了。更稳的做法是两层切分先按版面做结构切分比如标题、章节、条款再对长段落做滑动窗口切分同时保留重叠。这样每个向量聚焦的语义足够单一又不会把完整句子切断。3.2 一套能直接用的初始参数表下面这组参数是我在文档类问答项目里的起点不保证最佳但至少能跑出稳定基线参数初始值影响切片长度字符400太长语义发散太短丢上下文重叠长度50防止位于切片边界的关键句被切掉Top-K召回15初期宁多勿少给重排序留空间重排后保留数5最终进入大模型上下文的片段数Score 阈值0.2低于阈值时建议触发兜底策略如果平台支持按标题层级切分合同、政策、产品文档优先用它。JSON 配置示意如下{ chunk: { strategy: hierarchical, separators: [##, \n\n, 。], size: 400, overlap: 50 } }separators的顺序代表切分优先级先用##划章节再用空行划小节最后用句号兜底。size和overlap的单位取决于平台实现有的按字符、有的按 token先按字符设置并固定下来换平台时再做换算。3.3 校准切片拿一批真实坏 Case 反向调参只调参数不看 case 等于玄学。我一般会准备 20 到 30 个真实问题在开发环境逐个检索看最终返回的 chunk 是什么。用表格记录每个问题的预期片段、实际片段和失败类型。典型失败类型有三种。第一种答案在但排序太后调大 Top-K或者调高重排序保留数。第二种答案被切到了两个 chunk 里把切片长度降到 300同时加大 overlap 到 80。第三种错误片段总排第一多半是召回阶段被噪声词带偏需要在查询改写里去掉口语词。再补一个狠招按文件类型给不同切片配置。表格多的 Excel 适合按 Sheet 和行切PDF 合同适合按条款切。如果平台不支持细粒度分库可以靠文件前缀区分再用多条索引链路隔离。3.4 用配置即代码固化切片参数控制台手改参数有个隐患改完没人记得下次调参时找不到基线。我倾向把索引配置写成 YAML 放进项目仓库index_profile: chunk: strategy: hierarchical separators: [##, \n\n, 。] size: 400 overlap: 50 env: dev每次调整参数都改仓库、跑一遍离线评估、记下结果再合并。这样一来参数变化有记录出问题能回滚。别小看这一步RAG 项目里太多“我不记得上周改了什么”导致的返工。4. 检索与重排序优化让大模型“看到”更准的证据4.1 混合检索BM25 与向量互补纯向量检索在中文专有名词、型号、客户名上经常漏召回。“A2P-320B”这种字符串语义模型很容易把它当成无用结构而 BM25 这类稀疏检索能靠关键词精确匹配把它拉回来。所以只要平台支持建议直接开混合检索也叫 Hybrid Search。两路结果合并常用算法是 RRF。我自己实现过一版def rrf_fuse(ranking_a, ranking_b, k60): score {} for rank, doc_id in enumerate(ranking_a ranking_b): score[doc_id] score.get(doc_id, 0) 1 / (k rank 1) return sorted(score.items(), keylambda x: x[1], reverseTrue)ranking_a和ranking_b分别是两路检索返回的文档 ID 列表越靠前的文档贡献越大。k60是常用平滑系数k 越小排名差异越敏感。实际项目里我建议先用 RRF 跑出基线再考虑上重排序模型一上来就追求复杂融合往往连基线都没有。4.2 重排序把两阶段检索做完整第一次召回的目的是“别漏”第二次重排序的目的是“别错”。第一轮 Top-K 设 15 或 20重排后只保留 5 个再拼接进大模型上下文。加了重排序后噪声片段会被大幅压掉尤其是长文档场景提升非常明显。如果平台提供重排序开关记得这么设置参数建议值召回候选数量15重排序保留数量5不要为了省几次调用就跳过重排序。以为拿 Top-5 直接怼给大模型是在省钱实际是大模型每轮多读几段噪声输出质量和延迟双双变差得不偿失。4.3 查询改写当用户问题不像“检索词”时用户说“这个怎么走退款”文档里写的却是“退货退款流程”。不做查询改写向量检索很难把两边语义对齐。我在应用侧先让大模型做一次改写提示词模板如下把下面的用户问题改写成适合搜索引擎的查询只保留实体和关键词输出一行 用户问题{user_query} 改写关键是输出要克制不要解释更不要变成一段话。改写后再进 RAG 检索对“怎么办”“怎么弄”这类口语问题命中率提升明显。另一个技巧是“猜问题”对高频问题维护同义模板比如用户问“钱退哪”自动补成“退款原路返回需要几天”同时检索原始 query 和改写 query合并去重。代价是多了几毫秒检索耗时换来的召回稳定性很值。4.4 微调是最后手段不是首选我常看到团队检索没调好就急着微调模型结果知识库更新一次就要重新训练一次。微调解决的是输出风格、格式约束这类“模型侧”问题解决不了“证据没找到”的检索侧问题。正确顺序是先调切片、召回、重排序再用评估集跑基线确有必要微调时也只调特定术语的服从能力或输出格式不要试图把文档内容塞进模型参数。这份优化实践里的绝大多数收益都来自检索链路本身。5. 阿里云 RAG 常见问题与排查六个翻车现场修复全记录5.1 数据源显示“已同步”线上却一个片段都召不回现象控制台状态是已同步但测试问答时模型始终答“知识库没有相关资料”查检索日志发现命中数为 0。原因OSS 目录里的 PDF 是扫描件解析时 OCR 未开启文本段全是空白或者绑定目录时选错了前缀数据源根本没触发索引构建。解决先到数据管理里看解析详情确认非空 chunk 数量再直接在控制台预览一条文档内容看有没有可读文本。如果是扫描件更新解析配置并触发重建必要时先转成文本再上传。5.2 切分后全是“半句话”语义不完整现象召回片段最后几行停在“根据上述条”模型只能靠联想补完答案自然容易偏。原因固定长度切分把完整句子从中间切断没有采用按标点、换行的优先切分策略。解决把切分策略改成层级切分separators里优先用句号和换行切分后做一次“段落连贯性”校验把以连接词结尾的 chunk 直接丢弃或并入下一段。这个校验我放在构建脚本里一旦发现就报警而不是等用户反馈。5.3 Top-K 太小模型开始“自由发挥”现象答案读起来通顺但关键数据是编的或者说“具体政策请咨询客服”。整段话逻辑完整肉眼很难看出这是幻觉。原因证据片段没进入上下文模型只能靠预训练知识补全。这是 RAG 项目里最阴的问题因为输出流畅用户甚至会觉得答得挺好。解决上线前专门准备 10 条“数字题”比如“退款时限是多少”“抽成比例多少”。如果答案里找不到知识库里的数字说明召回数量不够。把 Top-K 从 5 拉到 15或者调低 score 阈值看是否能找回证据。5.4 改了源文件线上答案还是旧的现象人工更新了 OSS 里的文档重新上传后回答问题仍是上一版内容。原因没有触发增量同步或者平台的索引只解析了首次上传的文件。OSS 和索引之间不是实时绑定改文件不代表线上索引会跟着变。解决先把新文档单独传到新目录观察能否命中如果新目录可以说明是同步触发问题强制重建全量索引。全量重建期间可降级到旧索引但要在应用里加个标记避免用户拿到半新半旧的结果。5.5 调用 API 偶发 403本地跑通服务上报错现象本地代码测试正常部署到生产后调用百炼或 AI 搜索开放平台 OpenAPI 出现 403 或 InvalidPermission。原因RAM 子账号缺少对应权限或者 Endpoint 地域与 Bucket 不一致。比如把杭州的 Endpoint 用到了上海的资源上。解决检查 RAM 策略是否包含百炼和 AI 搜索开放平台的调用权限确认 Endpoint、Region 和 OSS Bucket 在同一地域。我一般会在部署脚本里加一段环境变量检查启动时打印当前 Endpoint防止配错。5.6 忘记约束“仅凭资料回答”现象有些回答明显超出知识库范围比如用户问“2027 年会不会降价”模型煞有介事地分析了一通。原因系统提示词没有约束模型只能依据检索片段作答模型把自身知识也带进来了。解决在系统提示词里固定写“只依据检索片段回答。缺少信息就直接说不知道禁止编造。”同时配合第 6 章的 Faithfulness 指标做回归防止后续改提示词时把这个约束冲掉。6. 让优化可度量离线评估集与 Ragas 三指标6.1 搭一套 100 条 QA 的离线评估集与其每次靠感觉调参不如建一个 100 条左右的评估集覆盖文档内事实、跨文档问题、否定问题、口语改写问题、多跳问题这几类。每条记录里写清楚预期答案的关键词这样跑完就能自动判分。评估集不是一次性资产。每次线上遇到 bad case就往里补充一条让回归集持续长大。否则你调了一版参数自我感觉良好结果一到线上就被新问题打回原形。6.2 看三个指标Faithfulness、Context Recall、Answer RelevanceRAG 优化最怕没有量化标准。我用 Ragas 这一类思路做评测核心看三个维度。Faithfulness 衡量忠实度也就是答案是否严格来自检索片段分数越低说明幻觉越多。Context Recall 衡量上下文召回率即检索片段里是否包含回答所需的全部信息这一项直接反映切片和检索的质量。Answer Relevance 衡量答案相关性即模型有没有真正回应问题。调切片和 Top-K 时重点看 Context Recall调提示词时重点看 Faithfulness。两个指标同时往下掉大概率不是参数问题而是源文档本身结构太乱。每次调参后把三个分数记在表格里对比比任何控制台手感都可靠。6.3 一版结果对比的模板版本FaithfulnessContext RecallAnswer Relevance备注基线0.720.580.81固定切分 1000 字符优化后0.890.830.90层级切分 混合检索 Rerank这种表我每调整一轮就更新一次。看着分数涨比单纯“感觉回答变好了”踏实得多。曾经我把 Top-K 从 3 拉到 15答案分数从 60 分提到 88 分这才意识到调检索参数是性价比最高的事。从那以后我每次调整切片或检索参数都强制走一遍这套评估集至少三个版本同分才敢放线上。希望帮到你。本文还有配套的精品资源点击获取 阿里云AI搜索RAG优化实践：从检索链路到评估指标
简介阿里云AI搜索RAG大模型优化实践PDF文档面向AI搜索、大模型应用与知识问答方向的算法工程师和技术决策者系统讲解RAG模型在文档解析、语义切片、信息召回、检索服务及大模型微调等关键环节的优化方法。资源为单个PDF文件大小17.76MB内容基于阿里云AI搜索团队的落地经验涵盖RAG架构全景、语义层级抽取模型、数据增强与模型训练、混合索引与重排、效果评测体系以及Agent与微调探索等实践模块。已有351人学习浏览适合在复杂文档场景中提升问答准确性、降低幻觉率并实现可溯源回答的读者参考。通过学习可掌握从文档结构化、切片语义补全到检索增强生成的可复用流程理解Qwen系列模型微调与Model-as-Judge评测工作流的应用技巧。1. 阿里云 AI 搜索 RAG 优化实践为什么你的检索总在浪费大模型算力我见过不少团队在阿里云 AI 搜索 RAG 项目上连续加班三周上线后用户问“为什么不能退款”模型却回复“请联系客服”而知识库里明明躺着完整的自助退款流程。问题通常不在大模型而在检索链路索引切得太粗、TOP-K 设得太小、重排序被当成口号。这份《阿里云 AI 搜索 RAG 大模型优化实践》PDF 讲的就是把“答非所问”修好的具体方法从切片参数、混合检索到重排序和离线评估一整套都能直接抄。适合已经跑通 demo、正被召回率和幻觉困扰的工程师也适合准备在阿里云上搭建知识库问答、想少走弯路的团队。2. 第一套阿里云 RAG 工作流组件选型与数据流转2.1 先分清三类“库”RAG 知识库、结构知识库与知识图谱很多人把 RAG 的瓶颈归结为大模型不行其实第一步就错了数据源被一股脑塞进同一个库。先把“库”的类型分清楚后面所有调参才有意义。RAG 知识库面向非结构化文本适合回答“这份合同里违约金怎么写的”“这个政策文件原文怎么说”。结构知识库面向表格、维表和可查询的数据库适合回答“某个型号的单价是多少”“这个订单处在什么状态”。知识图谱则面向实体关系适合多跳问题比如“哪些设备型号支持 5G 且具备 IP68 防水”。在阿里云环境里这三类数据经常混着来。但把订单表硬导进 RAG 知识库就成了一场灾难表格被拆成“列名 值”的碎片语义全断检索回来的段落像乱码。常见的做法是文档、公告、帮助中心文章进 RAG 知识库查状态、查数值、需要聚合的走 API 或结构化表多跳分析才考虑图谱。另外补充一个高频问题RAG 知识库能不能存图片能但前提是想清楚被检索的是图片里的文本还是图片本身。如果业务必须看图回答更可靠的做法是先把图片做内容提取或图生文再把生成的结构化描述送进索引而不是直接让向量模型去匹配一张无标签的 PNG。2.2 数据流转从 OSS 文档到线上索引整套 RAG 链路在阿里云上通常是这样的源文件先进 OSS再由平台做文档解析、切片、向量化最后落成在线索引。这个顺序不能乱因为解析和切片直接决定检索质量而 OSS 是阿里云上最通用的中间存储。上传数据这一步我用 ossutil 批量同步ossutil cp ./data/ oss://example-bucket/rag-docs/ --update --jobs 10 --force这个命令把本地 data 目录同步到 OSS 里。--update只上传本地有而远端没有的增量文件适合每天更新文档--jobs 10控制并发线程数带宽够时能明显加快大批量 PDF 的上传--force跳过交互确认方便在 CI 脚本里跑。传完之后到阿里云 AI 搜索开放平台或百炼控制台创建应用绑定这个 OSS 目录。平台会自动做文档解析和切片。初期建议先用默认的“智能切分”跑通全链路不要一上来就自定义不然你很难判断问题出在切分还是后面的检索。如果你上传的 PDF 大量是扫描件记得确认解析配置里 OCR 已开启。否则索引里全是空白文本后面检索命中率自然趋近于零。2.3 用校验逻辑把“索引不完整”暴露出来数据同步后别急着信控制台上的“已同步”。我每个项目都会跑一遍“三数校验”OSS 里的源文件数、平台上解析完成的文档数、实际切分出的 chunk 数。三者差异过大说明链路有环节静默失败了。import os local_docs [f for f in os.listdir(./data/)] print(f本地源文件: {len(local_docs)}) synced_docs get_platform_docs(app_id) # 替换成对应 SDK 的查询接口 chunks get_platform_chunks(app_id) # 获取索引段统计 print(f平台文档: {len(synced_docs)}, 索引段: {len(chunks)})这里的get_platform_docs和get_platform_chunks是示意函数实际实现要按你用的百炼或 AI 搜索开放平台 OpenAPI 替换。我的习惯是先传 10 份样例文档看切分后的 chunk 数是否在合理范围。一份 20 页的 PDF 正常能切出 80 到 150 个 chunk如果只有 2 个那大概率是解析直接失败了继续调检索参数没有任何意义。2.4 入口选型百炼和 AI 搜索开放平台怎么分工阿里云里做 RAG控制台上通常有两个长得像的入口百炼和 AI 搜索开放平台。我的理解是百炼偏“应用层”内置了模型调用、提示词模板、知识库和插件编排AI 搜索开放平台偏“检索层”把文档解析、向量索引、混合检索、重排序暴露成 OpenAPI你可以只接它的检索结果再喂给自己习惯的大模型。如果团队已有大模型 API或者想深度定制检索链路用 AI 搜索开放平台更顺手如果还在 MVP 阶段直接上百炼因为它已经把知识库和应用串好了开箱即用。更现实的建议是别两套并行。我早期项目就吃过双写的亏数据和权限各维护一套最后谁也不信谁。后来定下规矩检索统一走一个入口应用侧只做封装。3. 索引与切片参数决定召回上限的三套配置3.1 为什么直接整段塞进向量库会“翻车”很多团队图省事按文档原始段落直接 embedding一份 PDF 只有 10 段每段 3000 字。这样生成的向量会把多个主题混在一个向量里用户查询和它的相似度永远不痛不痒最终 TOP-K 里全是不沾边的结果。这不是大模型问题是检索输入的粒度错了。更稳的做法是两层切分先按版面做结构切分比如标题、章节、条款再对长段落做滑动窗口切分同时保留重叠。这样每个向量聚焦的语义足够单一又不会把完整句子切断。3.2 一套能直接用的初始参数表下面这组参数是我在文档类问答项目里的起点不保证最佳但至少能跑出稳定基线参数初始值影响切片长度字符400太长语义发散太短丢上下文重叠长度50防止位于切片边界的关键句被切掉Top-K召回15初期宁多勿少给重排序留空间重排后保留数5最终进入大模型上下文的片段数Score 阈值0.2低于阈值时建议触发兜底策略如果平台支持按标题层级切分合同、政策、产品文档优先用它。JSON 配置示意如下{ chunk: { strategy: hierarchical, separators: [##, \n\n, 。], size: 400, overlap: 50 } }separators的顺序代表切分优先级先用##划章节再用空行划小节最后用句号兜底。size和overlap的单位取决于平台实现有的按字符、有的按 token先按字符设置并固定下来换平台时再做换算。3.3 校准切片拿一批真实坏 Case 反向调参只调参数不看 case 等于玄学。我一般会准备 20 到 30 个真实问题在开发环境逐个检索看最终返回的 chunk 是什么。用表格记录每个问题的预期片段、实际片段和失败类型。典型失败类型有三种。第一种答案在但排序太后调大 Top-K或者调高重排序保留数。第二种答案被切到了两个 chunk 里把切片长度降到 300同时加大 overlap 到 80。第三种错误片段总排第一多半是召回阶段被噪声词带偏需要在查询改写里去掉口语词。再补一个狠招按文件类型给不同切片配置。表格多的 Excel 适合按 Sheet 和行切PDF 合同适合按条款切。如果平台不支持细粒度分库可以靠文件前缀区分再用多条索引链路隔离。3.4 用配置即代码固化切片参数控制台手改参数有个隐患改完没人记得下次调参时找不到基线。我倾向把索引配置写成 YAML 放进项目仓库index_profile: chunk: strategy: hierarchical separators: [##, \n\n, 。] size: 400 overlap: 50 env: dev每次调整参数都改仓库、跑一遍离线评估、记下结果再合并。这样一来参数变化有记录出问题能回滚。别小看这一步RAG 项目里太多“我不记得上周改了什么”导致的返工。4. 检索与重排序优化让大模型“看到”更准的证据4.1 混合检索BM25 与向量互补纯向量检索在中文专有名词、型号、客户名上经常漏召回。“A2P-320B”这种字符串语义模型很容易把它当成无用结构而 BM25 这类稀疏检索能靠关键词精确匹配把它拉回来。所以只要平台支持建议直接开混合检索也叫 Hybrid Search。两路结果合并常用算法是 RRF。我自己实现过一版def rrf_fuse(ranking_a, ranking_b, k60): score {} for rank, doc_id in enumerate(ranking_a ranking_b): score[doc_id] score.get(doc_id, 0) 1 / (k rank 1) return sorted(score.items(), keylambda x: x[1], reverseTrue)ranking_a和ranking_b分别是两路检索返回的文档 ID 列表越靠前的文档贡献越大。k60是常用平滑系数k 越小排名差异越敏感。实际项目里我建议先用 RRF 跑出基线再考虑上重排序模型一上来就追求复杂融合往往连基线都没有。4.2 重排序把两阶段检索做完整第一次召回的目的是“别漏”第二次重排序的目的是“别错”。第一轮 Top-K 设 15 或 20重排后只保留 5 个再拼接进大模型上下文。加了重排序后噪声片段会被大幅压掉尤其是长文档场景提升非常明显。如果平台提供重排序开关记得这么设置参数建议值召回候选数量15重排序保留数量5不要为了省几次调用就跳过重排序。以为拿 Top-5 直接怼给大模型是在省钱实际是大模型每轮多读几段噪声输出质量和延迟双双变差得不偿失。4.3 查询改写当用户问题不像“检索词”时用户说“这个怎么走退款”文档里写的却是“退货退款流程”。不做查询改写向量检索很难把两边语义对齐。我在应用侧先让大模型做一次改写提示词模板如下把下面的用户问题改写成适合搜索引擎的查询只保留实体和关键词输出一行 用户问题{user_query} 改写关键是输出要克制不要解释更不要变成一段话。改写后再进 RAG 检索对“怎么办”“怎么弄”这类口语问题命中率提升明显。另一个技巧是“猜问题”对高频问题维护同义模板比如用户问“钱退哪”自动补成“退款原路返回需要几天”同时检索原始 query 和改写 query合并去重。代价是多了几毫秒检索耗时换来的召回稳定性很值。4.4 微调是最后手段不是首选我常看到团队检索没调好就急着微调模型结果知识库更新一次就要重新训练一次。微调解决的是输出风格、格式约束这类“模型侧”问题解决不了“证据没找到”的检索侧问题。正确顺序是先调切片、召回、重排序再用评估集跑基线确有必要微调时也只调特定术语的服从能力或输出格式不要试图把文档内容塞进模型参数。这份优化实践里的绝大多数收益都来自检索链路本身。5. 阿里云 RAG 常见问题与排查六个翻车现场修复全记录5.1 数据源显示“已同步”线上却一个片段都召不回现象控制台状态是已同步但测试问答时模型始终答“知识库没有相关资料”查检索日志发现命中数为 0。原因OSS 目录里的 PDF 是扫描件解析时 OCR 未开启文本段全是空白或者绑定目录时选错了前缀数据源根本没触发索引构建。解决先到数据管理里看解析详情确认非空 chunk 数量再直接在控制台预览一条文档内容看有没有可读文本。如果是扫描件更新解析配置并触发重建必要时先转成文本再上传。5.2 切分后全是“半句话”语义不完整现象召回片段最后几行停在“根据上述条”模型只能靠联想补完答案自然容易偏。原因固定长度切分把完整句子从中间切断没有采用按标点、换行的优先切分策略。解决把切分策略改成层级切分separators里优先用句号和换行切分后做一次“段落连贯性”校验把以连接词结尾的 chunk 直接丢弃或并入下一段。这个校验我放在构建脚本里一旦发现就报警而不是等用户反馈。5.3 Top-K 太小模型开始“自由发挥”现象答案读起来通顺但关键数据是编的或者说“具体政策请咨询客服”。整段话逻辑完整肉眼很难看出这是幻觉。原因证据片段没进入上下文模型只能靠预训练知识补全。这是 RAG 项目里最阴的问题因为输出流畅用户甚至会觉得答得挺好。解决上线前专门准备 10 条“数字题”比如“退款时限是多少”“抽成比例多少”。如果答案里找不到知识库里的数字说明召回数量不够。把 Top-K 从 5 拉到 15或者调低 score 阈值看是否能找回证据。5.4 改了源文件线上答案还是旧的现象人工更新了 OSS 里的文档重新上传后回答问题仍是上一版内容。原因没有触发增量同步或者平台的索引只解析了首次上传的文件。OSS 和索引之间不是实时绑定改文件不代表线上索引会跟着变。解决先把新文档单独传到新目录观察能否命中如果新目录可以说明是同步触发问题强制重建全量索引。全量重建期间可降级到旧索引但要在应用里加个标记避免用户拿到半新半旧的结果。5.5 调用 API 偶发 403本地跑通服务上报错现象本地代码测试正常部署到生产后调用百炼或 AI 搜索开放平台 OpenAPI 出现 403 或 InvalidPermission。原因RAM 子账号缺少对应权限或者 Endpoint 地域与 Bucket 不一致。比如把杭州的 Endpoint 用到了上海的资源上。解决检查 RAM 策略是否包含百炼和 AI 搜索开放平台的调用权限确认 Endpoint、Region 和 OSS Bucket 在同一地域。我一般会在部署脚本里加一段环境变量检查启动时打印当前 Endpoint防止配错。5.6 忘记约束“仅凭资料回答”现象有些回答明显超出知识库范围比如用户问“2027 年会不会降价”模型煞有介事地分析了一通。原因系统提示词没有约束模型只能依据检索片段作答模型把自身知识也带进来了。解决在系统提示词里固定写“只依据检索片段回答。缺少信息就直接说不知道禁止编造。”同时配合第 6 章的 Faithfulness 指标做回归防止后续改提示词时把这个约束冲掉。6. 让优化可度量离线评估集与 Ragas 三指标6.1 搭一套 100 条 QA 的离线评估集与其每次靠感觉调参不如建一个 100 条左右的评估集覆盖文档内事实、跨文档问题、否定问题、口语改写问题、多跳问题这几类。每条记录里写清楚预期答案的关键词这样跑完就能自动判分。评估集不是一次性资产。每次线上遇到 bad case就往里补充一条让回归集持续长大。否则你调了一版参数自我感觉良好结果一到线上就被新问题打回原形。6.2 看三个指标Faithfulness、Context Recall、Answer RelevanceRAG 优化最怕没有量化标准。我用 Ragas 这一类思路做评测核心看三个维度。Faithfulness 衡量忠实度也就是答案是否严格来自检索片段分数越低说明幻觉越多。Context Recall 衡量上下文召回率即检索片段里是否包含回答所需的全部信息这一项直接反映切片和检索的质量。Answer Relevance 衡量答案相关性即模型有没有真正回应问题。调切片和 Top-K 时重点看 Context Recall调提示词时重点看 Faithfulness。两个指标同时往下掉大概率不是参数问题而是源文档本身结构太乱。每次调参后把三个分数记在表格里对比比任何控制台手感都可靠。6.3 一版结果对比的模板版本FaithfulnessContext RecallAnswer Relevance备注基线0.720.580.81固定切分 1000 字符优化后0.890.830.90层级切分 混合检索 Rerank这种表我每调整一轮就更新一次。看着分数涨比单纯“感觉回答变好了”踏实得多。曾经我把 Top-K 从 3 拉到 15答案分数从 60 分提到 88 分这才意识到调检索参数是性价比最高的事。从那以后我每次调整切片或检索参数都强制走一遍这套评估集至少三个版本同分才敢放线上。希望帮到你。本文还有配套的精品资源点击获取