少即是多:计算机视觉RAG里我删掉3层检索,幻觉率降了40%周一发版后,我蹲在工位上盯着监控屏--计算机视觉问答接口的幻觉率冲到了 31%。用户上传一张轴承照片问“密封圈材质”,系统回复“聚四氟乙烯”还附了一篇完全不相关的供应商文档。我后背发凉,这个基于 RAG 的视觉问答模块我们赶了两个月,上线当天就翻车。翻车当天我还没意识到根因在哪。更讽刺的是,后来帮我止血的不是堆更多检索规则,而是回炉一门生成式AI课--它把 chunk 策略、检索密度和幻觉之间的量化关系讲透了。如果你也做计算机视觉场景下的检索增强生成,这门课里的实验结论能帮你省掉至少两周的试错时间。计算机视觉为什么突然需要 RAG我们做的是一款工业质检的计算机视觉产品,核心是目标检测和缺陷分类。但客户提出新需求:不仅要知道零件有没有缺陷,还要能根据图片回答“这个零件的型号和上次入库有什么不同”“为什么这个区域被判为划痕”。这已经不是单纯分类能解决的。那时公司内部都在谈大模型落地,我们顺理成章在计算机视觉流程后接了一个 RAG 链路:用视觉模型提取特征,转化成文本描述,再检索知识库里的图纸、工艺文档、历史维修记录,最后让大模型生成答案。整个计算机视觉管道从“看图说话”变成了“看图 查资料 推理”。这个决定并不草率,我甚至还参考了人工智能入门课里介绍的多模态架构案例,课程把视觉与语言模型结合的方式梳理得很清晰,尤其适合从传统计算机视觉转到大模型的人。第一次搭建:我以为检索越多越准我们选用了一个开源向量数据库,把几百份技术文档按固定 512 token 切块,建了两个索引:一个基于图片描述文本,一个基于 OCR 提取的文字。检索时两边各召回 Top-5,再拼成上下文喂给大模型。我以为双路检索能提升覆盖面,甚至还加了一层重排序。一开始内部测试效果还行。但上线后,真实用户拍摄的图片角度、光照、遮挡差异很大,生成的图片描述经常跑偏,导致检索回来的文档和图片毫不相干。最离谱的一次,用户拍了个齿轮,系统因为 OCR 读到一角“润滑脂”字样,硬是检索出一篇关于食品级润滑剂的文档,最后生成“该零件适用于食品加工设备”。当时我还不知道,这个问题的根源可以追溯到对机器学习基础的忽视--尤其是特征空间中向量相似度与语义相关性的差异。那门机器学习基础课用整整一章讲嵌入空间的密度与噪声,如果早点补上,我就不至于在检索层狂堆规则。检索翻车:多层检索反而放大了幻觉灰度发布第二天,幻觉率没有下降,反而比单路检索时提升了 9 个百分点。我连夜加了第三层检索--用关键词匹配做精确过滤,结果更糟:系统开始过度依赖关键词,把只有“轴承”两个字的无关文档也拉了进来。当时我想当然地认为“检索层越多,信噪比越高”,但实际上每一层检索都在引入新的噪声源。为了排查,我不得不临时写评估脚本,统计每次检索回来的 chunk 与图片真实标签的相关性。这段工作我用了CodeWhisperer--在 VSCode 里写完函数名,它直接补全了 pandas 筛选和相似度计算逻辑,让我少写了至少 40 行代码。如果你日常需要快速编写数据处理脚本,CodeWhisperer的上下文补全确实能省掉大量机械劳动,尤其适合临时救火。# 用 CodeWhisperer 辅助生成的评估脚本片段 import pandas as pd from sklearn.metrics.pairwise import cosine_similarity # 读取线上日志,比较检索 chunk 与图片标签的相似度 def evaluate_retrieval(log_df, label_embeddings): hits 0 for idx, row in log_df.iterrows(): chunk_emb row[chunk_embedding] # 计算与真实标签的余弦相似度 sim cosine_similarity([chunk_emb], label_embeddings)[0] if max(sim) 0.7: # 阈值临时设定 hits 1 return hits / len(log_df)评估结果让我傻眼:三层检索后的 Top-10 chunk 里,平均只有 2.3 个与实际图片相关。也就是说,我们给大模型的上下文里,超过四分之三都是噪音。从课程里找到根因:chunk 大小与检索密度那个周末我没加班,而是把之前搁置的生成式AI课程翻出来重看。课程里有一节专门讲 RAG 的检索质量评估,用了一个我印象深刻的对比实验:同样一份文档,256 token 切块的检索相关性比 512 token 高出 21%,而 1024 token 切块时幻觉率开始显著上升。我立刻对照我们使用的 512 token 切块,正处在那个尴尬的中间地带--chunk 太大导致语义混杂,太小又丢失上下文连贯性。课程里给出的建议是:针对技术文档这类结构化文本,128-256 token 的滑动窗口切分往往能在召回率和精确率之间取得平衡。同时,我也重新梳理了深度学习入门中关于向量嵌入的章节,理解了高维空间中“最近邻”并不总是语义最相关的。这解释了为什么我们基于 OCR 碎片建立索引,反而加剧了误检。止血方案:删掉 3 层检索,重构 chunk 策略我做了三件事:砍掉多余的检索层:只保留经过语义对齐的图片描述索引,把 OCR 索引和关键词匹配层全部下线。重切文档:将所有技术文档按 200 token 滑动窗口重新切块,确保每个 chunk 只包含一个完整的信息点。引入相关性阈值:检索时只取与查询向量余弦相似度大于 0.75 的 chunk,宁少勿滥。上线前,我用之前积累的真实图片做了离线评估,这个指标在之前的日志里是 0.31,调整后直接跳到了 0.72。发版那天下午,我盯着监控:幻觉率从 31% 降到了 18%,又经过一轮 prompt 微调,最终稳定在 14%。虽然仍有优化空间,但至少不再给用户编造材质了。这次经历让我意识到,不是 RAG 不好,而是我少了一些关键认知。补上机器学习基础里的特征工程直觉,加上深度学习入门对嵌入空间的理解,才让我有能力做对 chunk 策略的选择。从计算机视觉到生成式 AI:我补了哪些课整个过程中,我陆续补了三类课程:生成式AI:搞懂了 RAG 架构的核心权衡,尤其是 chunk 大小、检索密度与幻觉率之间的量化关系。如果你也在做计算机视觉结合大模型的项目,这门课里的检索优化实验是直接能用的参考。机器学习基础:重新理解了嵌入空间、特征表达以及相似度度量的局限性。这些是调整检索策略的底层能力,没有它,我还在盲目堆规则。深度学习入门:深度学习入门课里关于 PyTorch 和向量操作的内容,让我能快速实现自定义的 chunk 评估工具,不用等人帮忙封装。同时,这门课的 AWS深度学习 相关实验教会我在云上用 GPU 实例跑 embedding 任务,节省了不少本地资源。另外,日常编码时CodeWhisperer帮我扛住了快速原型阶段的琐碎代码,从数据加载到结果可视化,它补全的代码块很少有逻辑错误,让我能腾出精力专注在模型逻辑本身。如果你习惯用 VS Code 或 JetBrains,Amazon CodeWhisperer对 Python 和数据处理场景的支持已经打磨得相当顺滑。给做计算机视觉 RAG 的同行几条建议从单路检索开始,严格评估后再加层:每一层检索都意味着新的噪声,没有数据支撑不要做加法。chunk 大小不是拍脑袋的:不同文档类型对应不同最优切分粒度,先做离线实验。生成式AI课里的那个 256 vs 512 的对比实验,我自己复现后才知道差距有多大。善用 CodeWhisperer 加速验证:评估脚本、数据清洗代码交给它,出错率低且风格统一,我算过至少省了 30% 的编码时间。向量相似度 ≠ 语义相关:这是机器学习基础教给我的最重要一课。如果检索质量差,不要急着调模型,先去检查你的嵌入质量和阈值。计算机视觉的多模态查询需要更好的对齐:图片描述质量直接影响检索效果,建议单独评估视觉模型输出的稳定性。把 RAG 当成一个系统问题,而不是单纯的模型问题:从 chunk 策略、检索方式、prompt 设计到评估体系,缺一不可。这次事故之后,我再回头看计算机视觉管线里的每一个环节,都比以前谨慎得多。如果你也在计算机视觉项目中集成 RAG,希望我的踩坑记录能让你少走一段弯路。