RAG检索精度0.6卡了两周,把chunk策略搬进Lambda后冲到0.91发版那天下午,产品经理把一张截图甩到群里--用户问「供应商付款账期」,系统答的是我们两家子公司合并前的旧条款。这已经不是第一次了。上线三周,企业知识库问答的幻觉率稳在31%,客户满意度跌到新低。我翻出项目启动那天列的学习清单,上面第一个就是机器学习基础,旁边潦草写着「跳过了,先上线再说」。现在回头看,正是当初那些跳过的坑--特征工程不当、数据预处理缺失、检索策略粗暴--联合起来把我拽进了幻觉的大坑。后来补这门课才发现,它从数据划分到模型评估讲得极细,学完就知道怎么把检索系统的每个环节对齐到业务目标,等于把整个机器学习管道的思维装进脑子里,再不是只会调参的CRUD工程师。为什么800字符的chunk让合同条款自相残杀项目组一开始图省事,直接把所有PDF按800字符切成固定块,塞进向量数据库。当时我以为这就是RAG的标准做法。结果那些跨页的法律条款经常被拦腰截断,导致一段文字前半截说「甲方有权」,后半截在另一个chunk里写着「...解除合同」,检索时经常拼出相反结论。后来我在特征工程这门课里才想通:chunk不是简单的字符串截断,而是一次特征的重新组织。好的数据预处理应该像特征提取一样,保留文档的结构层级。我把所有文档以标题、条款号为边界重新切分,并用AWS机器学习课程里学到的embedding评估方法,对比了三款模型在同一批chunk上的检索命中率,最终选了对法律文本语义区分最敏感的一款。重构那几天,我写了段Lambda函数来自动话整个分块逻辑:# Lambda函数:按Markdown标题层级进行动态分块 def chunk_by_headers(text, min_chars200, max_chars1200): 将文档按标题拆分成语义连贯的块 min_chars/max_chars作为硬边界,防止块过小或过大 sections [] current for line in text.split(\n): if line.startswith(#): if current and len(current) min_chars: sections.append(current.strip()) current line else: current \n line if len(current) max_chars: sections.append(current.strip()) current if current: sections.append(current.strip()) return sections把这段Lambda函数接入知识库的更新流水线后,每次有人上传新合同,自动触发分块和向量化,检索精度从0.6直接跳到0.85,但幻觉率还在18%--另一个坑还在等着我。换embedding那天,Lambda并发没控好差点烧掉一半预算检索精度上去之后,我发现大部分幻觉并非来自检索漏掉信息,而是检索回来的top-5段落里混进了看似相关其实无关的内容。根源在embedding模型本身--我们用的是开源小模型,对中文长句的语义区分度很差。于是我决定试亚马逊云科技机器学习平台上的Cohere Embed模型。换模型当天,我在Lambda里改了调用逻辑,为了提速,把并发上限直接拉到200。结果不到两小时,调用费用冲到快3000块,而且因为向量数据库写入速率跟不上,大量请求超时,线上服务开始降级。那个下午,我临时拉了一份机器学习管道的流程图贴在屏幕旁边。课程里反复强调管道的每个环节要有监控和回压控制,我把这些概念原样抄到了Lambda的配置上:# Lambda函数的环境变量配置片段 MAX_CONCURRENCY: 10 BATCH_SIZE: 20 BACKOFF_RETRIES: 3 CIRCUIT_BREAKER_TIMEOUT: 30配合SQS做缓冲,再把Lambda的预置并发降到10,系统跑了一个通宵没再炸。第二天查账单,日均调用费用压回预算的60%,而且换上新embedding后,检索准确率又往上窜了5个百分点。这次经历让我彻底明白,学AWS基础知识不是背产品手册,而是给自己的工程直觉装一套护栏。我写了个幻觉自检链,结果过拟合让检测器形同虚设查完检索的锅,我开始着手解决生成环节的幻觉。直接想到的办法是:让一个大模型读完检索到的段落和待生成答案,再做一次事实核查。我搭了一个检测prompt,用一批人工标注的「正确/幻觉」样本去调优检测模型的判断阈值。调了三天,检测器在验证集上F1到了0.96。我满心欢喜地上线,结果第二天日志里出现大量正常答案被判定成幻觉,触发重试循环,生成速度暴跌。排查下来,原因和我以前在深度学习入门课里翻过的车一模一样--训练集里正确样本太少,过拟合让模型学到「只要看到长段落就判幻觉」的捷径。我重新翻出混淆矩阵的笔记,统计了线上真阳性、假阳性比例,回头把检测prompt改成了这样:# 幻觉检测的改进prompt模板 detection_prompt 你是一个严格的事实核查员。给定以下参考资料和待核查文本, 判断是否存在以下三类错误中的任一种(有的话标出具体位置): 1. 数字/日期与参考资料不符 2. 将多条参考段落的信息错误拼接 3. 编造参考资料中未出现的实体或关系 参考资料: {retrieved_docs} 待核查文本: {answer} 请给出判定结论和具体证据。 同时把训练样本里正确例子的比例从15%补到40%,再上线时,假阳性率从34%压到7%,总算没白费力气。这件事让我特别后悔当初没先学过拟合那章就上手调检测器--机器学习入门课里那些老生常谈的基础,每一个都可能在生产环境变成真金白银的代价。给Lambda配上Step Functions后,整个RAG流水线从七手八脚变成一键触发前面几个坑填平后,系统散落着好几个Lambda函数:分块的、向量化的、检索重排序的、生成检测的。每次更新都要人肉串流程,一错就半天找不到上下文。后来在AWS深度学习课里看到一张用Step Functions编排Lambda的架构图,我照着把各环节串成了状态机:文档上传触发Lambda分块(S3事件源)分块完成写入SQS,第二个Lambda批量处理向量化检索时,由API Gateway触发串联Lambda,先检索、再生成、最后检测每步失败自动重试,状态可视化,故障定位从半小时缩到几分钟。这套Lambda驱动的管道跑了一个月,幻觉率从最开始的31%压到5%以内,检索精度从0.6提到0.91,整个知识库从每周被投诉三次,变成了零投诉。如果让我重来一次:给做RAG知识库的你的7条掏心建议在碰任何向量数据库之前,先把数据预处理做透--chunk策略要根据文档结构定,不是拍脑袋的800字符。想搞清不同策略对最终效果的影响权重,翻一遍机器学习基础里的特征工程那章就全明白了。embedding选型别省钱用开源小模型,除非你能承受检索环节的噪声引入。亚马逊云科技机器学习上有现成的模型对比工具,值得花两小时跑一遍再用Lambda封装调用。Lambda的并发控制在云上就是预算控制器,别像我一样一把拉满。先去看AWS基础知识里关于无服务器架构的并发模型,再动手。做幻觉检测时,如果自己训一个判别模型,一定要保持训练集中正负样本的平衡,否则过拟合会教你做人。不要跳过机器学习管道的监控设计。每次数据一变动,模型表现就波动,没管道思维就只能靠用户投诉来发现。深度学习入门学一遍PyTorch或TensorFlow的实战项目,对理解embedding的生成机制有巨大帮助,尤其当你要自己做领域适配的时候。当你的RAG系统散落着三四个Lambda函数时,赶紧上Step Functions串起来。状态机图就是你的系统文档,排查效率翻倍,这也是从AWS机器学习实战课里捡到的好习惯。