搜索中文正文和常见中英文技术词,按教程、项目、面试题筛选。
「检索 Embedding 评估」找到 264 条内容
按专题浏览 →匹配正文:…先,按条款编号切分;添加父级标题作为上下文前缀 特殊处理:法条引用关系需建图索引,不依赖纯文本切块 关键权衡 粒度vs召回:块越小检索准但可能丢上下文,块越大完整但噪声多 建议:实际采用多粒度索引——小chunk用于精排,大chunk(或父文档)用于生成时补充上下文 评估方法 检索侧:Top-K命中率、MRR 生成侧:答案完整性人工评分、引用准确率 学习建议 建议从基础切块方法(如固定长度、按段落)入手,理解其在专业文档中的局限;再学习语义切块等高级策略,结合实际案例练习分块…
匹配口述回答:[[Chunking]] 对 [[RAG]] 的影响非常大,因为它决定了知识库里最小的检索单元。切得好,检索能找到刚好回答问题的证据;切得不好,要么找不到,要么找回来一堆噪声,最后生成模型也会被带偏。 它的核心权衡是信息粒度和上下文完整性。块太小,语义容易断,比如一句“该方法效果更好”被单独切出来,模型不知道“该方法”指什么;块太大,里面噪声多,[[embedding]] 会被多个主题稀释,检索精度下降,塞给大模型也浪费窗口。 常见方法里,固定长度分块最简单,按 token …
…论文、报告、企业SOP这类有完整语义的文档,就得按语义边界来切。按句子、段落,甚至按标题和章节来切。这样切出来的块内部语义自包含,检索精准度高。但这里有个前提:文档结构要清晰。如果是一份没有标题、没有分段、格式混乱的[[OCR]]扫描件,语义切分效果会大打折扣。而且块大小不均匀,对后续的[[Embedding]]和检索延迟有影响。 所以真正落地的时候,我倾向于把两者结合起来。一个很实用的做法是多粒度设计,也叫Parent-Child结构。较小块负责精准命中,较大父块负责补回生…
学习内容与项目面试,在同一条路上。