搜索中文正文和常见中英文技术词,按教程、项目、面试题筛选。
「RAG链路」找到 189 条内容
按专题浏览 →匹配口述回答:[[RAG]] 出错时,我不会先凭感觉说是检索的问题还是生成的问题,而是做隔离变量实验。因为 RAG 是串联系统,前面检索错会传导到生成,生成模型也可能在检索正确的情况下自己发挥,所以要把两个模块拆开看。 答案跑题、数字错误或引用缺失只能作为排查线索,不能直接归因。检索和生成可能同时失败,必须用黄金证据替换、重复对照和证据级指标隔离变量。 第一步看检索 TopK。检查正确文档有没有被召回,排在第几位。如果正确文档根本不在 TopK,基本就是 retriever 召回问题,对应…
匹配口述回答:…ch]],就是向量加[[BM25]]关键词,结合起来,再经过[[Rerank]]重排,才能把最相关的那几段送到模型面前。 再一个,RAG的评估也是个头疼事。你不能只看模型回答得顺不顺,还得看它有没有忠实于检索到的文档,有没有忽略关键信息。我倾向用[[RAGAS]]这类框架做自动化评估,但最终还是得人工抽检。 所以,我会把RAG看成是让大模型在真实业务里落地的必选项,但不是银弹。它解决了知识时效和幻觉的问题,但前提是知识库本身得可靠、检索链路得精细。我更倾向在架构设计时,就预留…
匹配口述回答:…而不预先保证结果。 但这里有个延伸点:如果知识库本身有错,或者更新不及时,RAG 反而会引入错误。所以我现在更关注 [[Self-RAG]] 这种让模型自己反思检索结果的技术。你怎么看这种方案的价值和局限性? 最后说我的判断:我更倾向把 RAG 作为第一道防线,因为它可解释、可溯源,简单实现也可以复用现有模型,按任务需要再考虑检索器或生成器训练。RLHF 是第二道防线,用来打磨表达。如果资源有限,我会优先把 RAG 的检索链路做扎实,因为知识错了,表达再好也没用。 一句话定位…
学习内容与项目面试,在同一条路上。