当前位置:首页 > 文章列表 > 科技周边 > 人工智能 > Embedding 结果怎样保留文本分块位置方便回溯

Embedding 结果怎样保留文本分块位置方便回溯

来源:17golang原创 2026-10-17 23:31:46 0浏览 收藏

Embedding 的结果不要只保存一串向量和相似度。更稳妥的做法是把每个向量当成“原文分块的索引记录”,同时保存文档标识、文档版本、分块编号、字符起止位置和必要的内容摘要。召回时先用向量找候选,再依据这些字段回读原文,这样排序和引用都不会丢掉来源。

官方地址:https://www.sbert.net/docs/sentence_transformer/usage/usage.html

下面的结构不绑定某一个向量数据库。无论底层使用哪种索引,关键都是把“用于相似度计算的向量”和“用于原文回溯的元数据”放在同一条可关联记录中。

先把向量和来源元数据绑定

一条可回溯记录至少需要 doc_id、doc_version、chunk_id、start_offset、end_offset 和 text_hash。向量负责近似检索,元数据负责回答“它来自哪份文档的哪一段”。

原文分块、Embedding 向量、向量索引与来源元数据绑定关系的静态结构图
图1:把分块位置和文档标识随向量一起保存的结构示意图,不是截图或运行证据。
# 用不可变的来源字段描述一个向量对应的原文分块
chunk_record = {
    "doc_id": "handbook-17",
    "doc_version": "2026-10-17T01",
    "chunk_id": "handbook-17:0042",
    "start_offset": 18320,
    "end_offset": 18976,
    "text_hash": "sha256:示例摘要",
    "text": "只保留用于展示或回读的分块文本"
}

# 向量索引只负责近似搜索,metadata 保留回溯所需字段
index_record = {
    "id": chunk_record["chunk_id"],
    "vector": embedding,
    "metadata": chunk_record
}

这里的 chunk_id 要稳定且可读,不能只用一次性数组下标。下标会随着重切片改变,而稳定 ID 能帮助日志、缓存和引用指向同一份来源记录。

记录字符偏移、版本和切块规则

只保存分块文本也能做简单展示,但一旦原文被更新,就很难判断旧文本是否仍然有效。建议把文档版本和切块规则一起记下:版本用于确认偏移的参照物,规则用于解释为什么相邻分块有重叠或为什么某段被拆开。

# 元数据描述偏移的参照版本,避免把旧偏移套到新正文上
provenance = {
    "doc_id": "handbook-17",
    "doc_version": "2026-10-17T01",
    "chunk_id": "handbook-17:0042",
    "start_offset": 18320,
    "end_offset": 18976,
    "splitter": "paragraph-800-overlap-120",
    "text_hash": "sha256:示例摘要"
}

# 只有同一版本的正文,偏移才可以直接切片
if source_version != provenance["doc_version"]:
    raise ValueError("文档版本不一致,不能直接使用旧偏移")
source_text = source_text[provenance["start_offset"]:provenance["end_offset"]]

偏移单位必须固定。Python 字符串按 Unicode 码点切片时,和按 UTF-8 字节计数并不是一回事;如果数据链路中有其他语言或服务,应该显式记录偏移单位,例如 unicode-codepoint 或 utf8-byte,不要靠约定猜测。

召回结果里不要丢来源字段

召回阶段通常会返回 score 和记录 ID。真正交给生成模型或前端的结果,还应该带上来源元数据,至少包括文档标题、章节、分块 ID 和版本。这样排序只改变候选顺序,不会把可追踪信息截掉。

# 将向量检索命中的记录整理成可引用的候选项
def to_citation(hit):
    metadata = hit["metadata"]
    return {
        "score": hit["score"],
        "doc_id": metadata["doc_id"],
        "doc_version": metadata["doc_version"],
        "chunk_id": metadata["chunk_id"],
        "start_offset": metadata["start_offset"],
        "end_offset": metadata["end_offset"],
        "text": metadata["text"]
    }

# 只把完整来源对象交给后续排序或回答阶段
citations = [to_citation(hit) for hit in search_hits]
citations.sort(key=lambda item: item["score"], reverse=True)

不要把 score 当成来源证明。分数只能说明候选与查询的相似程度,不能说明文本来自哪个版本,也不能证明答案覆盖了完整上下文。来源字段应与候选一起流转到最终引用层。

按偏移回读原文,并处理版本失配

如果业务要求展示原文的最新内容,可以在回读时再次检查版本和哈希。版本一致时直接按偏移取片段;版本不一致时,不要静默使用旧偏移,可以回退到保存的分块文本,或者按 chunk_id 查找重建后的映射。

用户问题经过向量召回后携带文档版本、分块编号和字符范围回到原文的静态示意图
图2:召回、排序到原文回读的来源链路示意图,不是截图或运行证据。
# 回读时同时检查文档版本和内容摘要,避免错引新旧文本
def resolve_source(hit, documents):
    meta = hit["metadata"]
    document = documents.get(meta["doc_id"])
    if document is None:
        return {"status": "missing-document", "text": meta["text"]}

    # 版本不同代表偏移参照物已经变化,不能直接切片
    if document["version"] != meta["doc_version"]:
        return {"status": "stale-version", "text": meta["text"]}

    text = document["text"][meta["start_offset"]:meta["end_offset"]]
    if hash_text(text) != meta["text_hash"]:
        return {"status": "hash-mismatch", "text": meta["text"]}
    return {"status": "ok", "text": text}

三种异常状态的含义不同:文档不存在是存储问题,版本过期是索引需要重建或映射的问题,哈希不一致则说明切块内容与记录不符。把它们分开记录,比统一返回“找不到原文”更容易排查。

用最小数据结构检查回溯闭环

字段用途缺少后的影响
doc_id定位原始文档无法知道候选来自哪里
doc_version确认偏移参照物新旧文本可能错位
chunk_id定位稳定分块日志与引用难以关联
start/end_offset回读精确范围只能展示整段或保存副本
text_hash检查内容是否一致难以发现分块已被替换

可以把闭环压缩成一句判断:向量命中后,能否通过同一条记录找到文档、确认版本、定位分块,并在内容变化时给出失配状态。如果只能拿到分数和一段孤立文本,就还没有完成可回溯设计。

常见问题

只保存分块文本,不保存字符偏移可以吗?

可以满足简单展示,但当原文需要更新、引用或审计时,缺少偏移和版本会使来源关系变得模糊。至少应保存文档 ID、版本和分块 ID。

字符偏移和分块编号哪个更重要?

两者用途不同:分块编号适合稳定关联向量和日志,字符偏移适合从指定版本原文中精确回读。可回溯链路通常同时保存。

重切片后旧向量怎么办?

不要把旧向量伪装成新版本。为新切片生成新的分块 ID 和版本,旧记录标记为过期或移出检索范围,再按业务需要保留历史引用。

相似度分数高就能直接当作引用吗?

不能。分数只参与排序,引用还需要来源元数据、版本检查和原文回读结果。

小结

Embedding 的可回溯性来自数据结构,而不是来自模型本身。把 doc_id、doc_version、chunk_id、字符偏移和内容摘要与向量绑定,召回后保留这些字段,并在回读时检查版本与哈希,就能把“相似候选”变成“有来源的候选”。

版本声明
本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
RAG 检索怎样用元数据过滤租户内容RAG 检索怎样用元数据过滤租户内容
上一篇
RAG 检索怎样用元数据过滤租户内容
AI 工具调用参数怎样用枚举收窄输入
下一篇
AI 工具调用参数怎样用枚举收窄输入
查看更多
最新文章
查看更多
课程推荐
  • 前端进阶之JavaScript设计模式
    前端进阶之JavaScript设计模式
    设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
    543次学习
  • GO语言核心编程课程
    GO语言核心编程课程
    本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
    516次学习
  • 简单聊聊mysql8与网络通信
    简单聊聊mysql8与网络通信
    如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
    500次学习
  • JavaScript正则表达式基础与实战
    JavaScript正则表达式基础与实战
    在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
    487次学习
  • 从零制作响应式网站—Grid布局
    从零制作响应式网站—Grid布局
    本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
    485次学习
查看更多
AI推荐
  • PubMedQA数据集详解:生物医学问答基准、功能与应用指南
    PubMedQA
    深入了解PubMedQA生物医学问答数据集,涵盖其核心功能、使用方法及在临床决策、药物研发等场景的应用,助力提升NLP模型性能。
    510次使用
  • H2O EvalGPT:开源LLM大模型评估与排行榜工具
    H2O EvalGPT
    H2O EvalGPT是H2O.ai推出的开源LLM评估平台,提供详细的大模型性能排行榜、行业特定基准测试及A/B测试功能,助您快速选择最适合项目的高性能大语言模型。
    570次使用
  • LMArena是什么?伯克利AI模型评估平台使用指南与功能解析
    LMArena
    LMArena是加州大学伯克利分校推出的AI模型匿名评测平台。通过盲测投票机制,用户可对比不同大模型回答并生成实时排行榜,助力开发者优化模型及用户选择最佳AI工具。
    594次使用
  • 斯坦福HELM:大语言模型Holistic Evaluation整体评估框架详解
    HELM
    深入了解斯坦福推出的HELM(Holistic Evaluation of Language Models)大模型评测体系。本文解析其核心功能、安装配置步骤及应用场景,涵盖准确性、公平性、鲁棒性等多维度指标,助力开发者全面优化语言模型性能。
    547次使用
  • MMBench详解:多模态大模型基准测试、功能特点与使用指南
    MMBench
    MMBench是由上海人工智能实验室等机构联合推出的多模态基准测试平台,提供细粒度能力评估、大规模数据集及VLMEvalKit工具。本文详细介绍其核心功能、安装使用方法及应用场景,助力开发者全面评估多模态模型性能。
    364次使用