向量检索 RetrievalScoring打分 Chunk Overlap块重叠完整讲解一、Scoring 相似度打分检索排序核心1. 核心作用向量检索时数据库会计算查询向量 Query和库内每条文档块向量的相似度分数用分数做排序分数越高代表语义越匹配只返回 Top-N 高分结果。 主流 3 种打分算法向量数据库通用余弦相似度 Cosine SimilarityChroma、Milvus、Pinecone 默认适用归一化后的 Embedding 向量几乎所有现代嵌入模型输出都会归一化分数区间[-1, 1]业务中只会出现[0,1]1 语义完全一致0 完全无关优势不受向量长度影响只对比方向文本检索首选L2 欧氏距离 L2 Distance逻辑和余弦相反数值越小越相似缺点受向量模长干扰Embedding 场景极少单独用点积 Dot Product归一化向量下结果等价余弦相似度计算速度更快OpenAI Embedding 常用2. Retrieval 流程里 Scoring 完整链路用户提问 → 用同个 Embedding 生成 Query 向量ANN 索引快速召回一批候选向量粗召回不精细打分对候选集做精确 Scoring精排计算每条相似度分数按分数从高到低排序截取 Top K 片段交给 LLM 做生成3. 业务调优关键点分数阈值过滤设置score_threshold0.7低于阈值直接丢弃无关文档减少 LLM 冗余上下文重排 Rerank粗召回 Scoring 后用交叉编码器再二次打分大幅提升精准度元数据过滤前置先按标签 / 时间筛数据再打分减少计算开销举例Chromapython运行results collection.query( query_texts[向量数据库打分原理], n_results5, score_threshold0.7 # 只返回余弦分≥0.7的块 ) # results[distances] 存储每条对应的余弦距离/分数二、Chunk Overlap 文本块重叠分块策略核心参数1. 定义做文档 Chunk 分片时相邻两个文本块重复截取一段文字重复的字符长度就是 overlap 重叠长度。 举例chunk_size500单块 500 字chunk_overlap100重叠 100 字 块 10~500 字 块 2400~900 字 块 3800~1300 字 相邻块中间 100 字完全重复。2. 为什么检索必须加 Overlap解决核心缺陷无重叠分块致命问题关键语义被切在两块边界例完整知识点「Embedding 向量通过余弦 Scoring 完成检索排序」 切分刚好卡在中间 块 1 结尾Embedding 向量通过余弦 块 2 开头Scoring 完成检索排序 用户提问 “向量怎么打分检索”单独检索任意一块都缺失完整上下文语义断裂、Scoring 分数偏低检索漏结果。重叠机制让完整跨边界句子同时存在两块里检索时至少有一块携带完整语义大幅降低漏召、提升检索匹配分数。3. Overlap 参数取值标准RAG 行业通用overlap 推荐设置为 chunk_size 的10%~20%短文档、短句知识库API 文档、教程 chunk_size300overlap50~60长文本、论文、技术手册你现在向量数据库资料 chunk_size500~800overlap100~150超大完整书籍 chunk_size1000overlap2004. Overlap 带来的副作用权衡取舍向量数量翻倍入库、检索性能轻微下降内存占用变高检索返回重复片段送入 LLM 前需要去重否则浪费上下文窗口overlap 过大超过 30%大量重复向量检索冗余严重速度明显变慢5. 和 Scoring 的联动关系合理 overlap → 完整语义不被截断 → 文档块向量和 Query 向量相似度更高 → Scoring 分数提升更容易排在 Top 结果0 overlap无重叠→ 边界语义断裂 → 匹配分数降低极易被阈值过滤丢失关键信息三、两者协同工作完整链路RAG 检索标准流程文档分块chunk_size600, overlap120生成带重叠连续文本块向量化入库所有块用同一 Embedding 生成向量存入 Chroma用户提问生成 Query 向量ANN 索引粗召回候选集Scoring 计算每条块余弦相似度按分数排序过滤低分块返回 Top N 高匹配文本给大模型生成回答极简总结Scoring检索的排序标尺用余弦等算法衡量 query 和文档块的语义相似度Chunk Overlap分块优化手段给相邻文本增加重复内容避免知识点被切割间接提高检索 Scoring 分数、减少漏检索。
