RAG返工三次后,我停掉所有优化去补生成式AI基础,反而救活了项目公司内部知识库问答系统内测那天,测试同事在群里贴了张截图:问的是「离职补偿金审批流程」,模型给出的回答却把绩效申诉和竞业限制条款混在一起,还煞有介事地标了“详见第4.2节”。我盯着那条仿佛喝醉了的回答,背后的压力一下子涌上来--这已经是第三次返工,再搞不定,项目就要被砍。在那之前,我已经把能想到的检索优化全部撸了一遍:换 Milvus、调相似度阈值、试了 HNSW 和 IVF Flat 两种索引,甚至把文档按标题和正文分开向量化。每一次内测,幻觉率都从 40% 往下降一点,但就是压不下去。直到技术总监丢来一句话:“你是不是该回去看看生成式 AI 的基础原理,而不仅仅在检索上死磕?” 这句话后来让我在亚马逊云科技的生成式 AI 课程里直接找到了根因--课程把大模型如何处理上下文、怎么构建 prompt、检索结果怎么拼接才能抑制幻觉,用几小时讲得明明白白。就凭这个,点击生成式 AI 课程能看到全套 RAG 架构拆解和实战案例,直接帮我把项目的方向掰了回来。为什么检索越调越准,答案却越来越胡扯我的逻辑一度很“朴素”:只要把最相关的文档片段喂给大模型,它自然就能整合出正确答案。于是整个项目的前六周,我都在和召回精度较劲。下面这段代码就是当时用来获取上下文的函数,基本就是拿余弦相似度直接排序、取 top-5 然后拼接:# 早期的上下文构建:简单粗暴的 top-k 拼接 def get_context(question, index, k5): emb encode(question) # 用 text-embedding-ada-002 编码 docs, scores index.search(emb, k) # 向量检索 context \n\n.join(docs) # 直接拼接,不做任何过滤 return context表面看这个思路没问题,但很快我就发现一个诡异现象:检索到的文档确实和问题相关,可大模型却常常在回答里夹带一些原文根本没有的信息。后来我在生成式 AI 课程中才弄懂,这其实是“上下文干扰”的典型表现。课程里用一张图拆解了 RAG 的数据流,明确指出当 chunk 过大、包含多条不相关的子主题时,模型会无差别地“看到”所有信息,并在生成时根据内部概率拼接成看似合理的错误答案。如果你也在踩同样的坑,生成式 AI 课程会一步步演示怎么诊断这类问题,比一个人在日志里闷头排查高效得多。暂停所有调参,回头啃「生成式 AI」基础连着两次上线失败后,我做了一个当时看起来很“倒退”的决定:停掉所有索引参数的调整,把时间全部用来补基础。我报了亚马逊云科技那门面向技术人员的生成式 AI 课程,从大语言模型的预训练、对齐到 RAG 架构全景,一节一节啃。学到第二周,一个概念直接打醒了我:上下文窗口内的信息密度。生成式 AI 课程里有一个实验模块,手把手让学员用不同 chunk 策略构建上下文,然后对比生成结果的准确率。我按课程里的方法,在自己项目的数据集上重跑了一遍,结果如下:策略chunk size是否保留前后文幻觉率 (内部测试集)回答相关度我的老方案512 tokens否41.2%76.3%课程建议 A256 tokens否28.6%83.1%课程建议 B256 tokens是 (overlap 64 tokens)12.7%91.5%这个对比表就是压垮“痴迷检索调参”的最后一根稻草。同样都是 Milvus 向量库,只是改了分块策略和上下文拼接方式,幻觉率从四成多直接降到一成出头。生成式 AI 课程把这种“分块→上下文→prompt”的链路拆解得非常细,学到这我已经基本确定,之前的优化方向根本偏了。与此同时,为了补充 embedding 和检索的底层原理,我又回炉了机器学习基础中的相似度计算部分,以及深度学习入门里对 Transformer 注意力机制的讲解--这两门课把向量检索背后的数学直觉补上了,让我后面调 chunk 时能做到心中有数,而不是瞎试参数。人工智能入门则适合团队里转行来的同事快速建立整体认知,帮他们在一周内就能参与 RAG 的开发讨论。重新设计 Chunk 与 Prompt:用课程方法止血明确方向后,我马上重写了文档切分和上下文构建的代码。这次的核心原则来自生成式 AI 课程里的两张图:一张是“chunk 与语义边界”的示意图,另一张是“带约束的 prompt 模板”。我把 chunk 大小控制到 256 tokens,并让相邻 chunk 之间有 64 tokens 的重叠,确保关键信息不会在边界处被截断。改写后的分块代码如下:from langchain.text_splitter import RecursiveCharacterTextSplitter # 根据生成式 AI 课程的建议,使用小 chunk 重叠窗口 splitter RecursiveCharacterTextSplitter( chunk_size256, chunk_overlap64, separators[\n\n, \n, 。, ], keep_separatorTrue ) chunks splitter.split_documents(docs)上下文构建也不再是简单的 top-k 拼接,而是为每个检索到的 chunk 附带其前一个和后一个 chunk 的首句,作为“锚点”。这样一来,大模型在看到一段文本时,能自动感知到前后语境,不会孤立地理解某个片段。与此同时,我把 prompt 也彻底改了一遍。以前我只会写“请基于下面的资料回答问题:”,现在按课程里的“引用强制”模板,要求模型在生成时标注来源句子并拒绝回答资料未覆盖的内容:prompt_template 你是一个仅基于给定资料回答问题的助手。 如果资料中没有足够信息,请直接回答“根据现有资料无法确认”,禁止编造。 资料: {context} 问题:{question} 请严格按以下格式输出: 答案:(用资料中的句子支撑) 引用来源:(标明 chunk 编号和原文) 这段代码实际上是在亚马逊云科技的 CodeWhisperer 协助下快速写完的--写好注释要求,按 Tab 自动补全,再修几个变量名,十分钟就搞定了 prompt 模板和分块函数的重构。CodeWhisperer 在写这些数据处理和格式化代码时几乎不出错,帮我省掉了至少 30% 的杂活时间,让我能集中精力去想 chunk 策略和效果验证。幻觉从 40% 降到 3%,项目救活了改造后重新跑内部测试集的结果,让我第一次在项目上感到踏实。同样是 200 条业务高频问题:回答与资料严格匹配的比例从 58.8% 提升到 96.7%,幻觉率被压到 3.3%。在用户“追问”场景下,由于 chunk 重叠带回了上下文,模型对多轮问题的信息遗漏从之前的 34% 降到了 6%。一次回答的平均生成时长几乎没有增加,因为 chunk 虽然多了,但每个 chunk 更短,模型处理的 token 总量反而略降。真正让我后怕的是,如果当初继续死磕检索算法,我可能再过两个月也达不到这个效果。生成式 AI 这门课最大的价值不是给了哪个银弹配置,而是帮我把 RAG 的出错模式--信息混淆、上下文过窄、生成不受控--一条一条梳理清楚。后面我把整套设计和分步实验记录写成了一份内部文档,研发部门现在接到新的 RAG 需求,都会先按这个流程做基线测试。给同样在 RAG 上翻车的人的五条建议如果你正在 RAG 项目上反复调参数、却始终压不住幻觉,请先把手上的优化停下来,从这几点入手:排查 chunk 策略,而不是检索排序。很多幻觉不是检索错了,而是 chunk 里混进了无关信息。建议把 chunk size 压到 256 token 以下,并开启重叠。想知道 chunk 策略怎么具体设计,生成式 AI 课程里有一套“信息边界检测”的方法,值得点进去对着自己的文档试一遍。强制引用,不给模型编造的空间。用 prompt 模板约束模型只能基于资料回答,并要求标注来源。这个思路同样在生成式 AI 课程的 prompt 工程部分有详细拆解。补上生成式 AI 的基础链路。如果你只是看了几篇 RAG 的博客就开始写代码,很容易忽略大模型对上下文和概率生成的底层假设。生成式 AI 课程从模型原理讲到 RAG 全流程,几小时就能把零散的知识串联成体系。让团队里不同背景的人都能跟上。转行的同事可以先从人工智能入门开始建立 AI 全局认知,再结合实际项目理解 RAG;想深入调优检索的,可以补一下机器学习基础和深度学习入门中关于嵌入和注意力机制的内容,比只看 API 文档有效得多。用 AI 编程助手提效,把时间花在决策上。像 CodeWhisperer 这类工具在处理数据切分、格式化、模板拼接等重复性代码时非常可靠,省下的大量时间可以用在实验设计和效果评估上。RAG 本身不复杂,但它把检索、生成、知识表示几个领域揉在了一起,任何一环的误区都会被大模型“戏剧化”地放大。补对基础,真的比调一万个参数管用。