搜索中文正文和常见中英文技术词,按教程、项目、面试题筛选。
「RAG 语义匹配」找到 52 条内容
按专题浏览 →匹配口述回答:…回率和MRR,用一批标注好的query-doc对来评估。在线我会抽检人工看召回的相关性,建立bad case闭环。特别要注意的是,RAG不是向量化就完事了,如果检索结果质量差,生成必然跑偏。所以上线前我会用历史query回放,对比新旧流程的召回率和延迟,通过才切换,不通过就回滚。 最后说边界。分块和模型选型没有银弹,固定切分适合日志、代码这种结构简单的,语义切分适合新闻、报告;稠密向量适合语义匹配,稀疏向量比如[[BM25]]适合关键词精确匹配,真正落地常常两者混合。我倾向用…
匹配口述回答:…然流畅。端到端就是最终答案对不对,但这里有个坑:如果检索召回很低,但生成答案居然对了,那很可能是模型靠参数记忆作弊,这种场景下你的RAG其实没生效。所以三层指标要一起看,才能定位到具体瓶颈。 迭代优化,我遵循先诊断后动手。举个例子,客服退款场景,用户问“我买了件衣服尺码不对怎么退”,如果检索没召回退款政策文档,那就是召回不足。我会用[[混合检索]],[[BM25]]加向量,再加[[重排]],把关键词匹配和语义匹配结合起来。如果召回够但生成还是瞎编,那就强制引用,让模型必须标注…
…够了再切到DPR。真正上线时,我几乎一定会把向量检索和关键词检索结合起来,也就是 [[Hybrid Search]],因为向量擅长语义匹配,但精确匹配比如订单号、政策条款号,还是[[BM25]]更靠谱。 怎么评估编码模型的检索能力?RAG场景下,我最看重的是 Recall@K,比如Recall@5。为什么?因为生成阶段能容忍一些噪声,你给大模型十段文档,哪怕其中两三段不相关,它也能挑出有用的信息。但如果你漏掉了关键文档,大模型就真不知道,那它就可能会瞎编,也就是 [[Hall…
学习内容与项目面试,在同一条路上。