北京
想象一下，你拿到一份精密的技术规格书，然后拿起剪刀，每五百个词就咔嚓一刀。不管标题在哪里，不管章节从哪开始到哪结束，也不管一段完整的思路是否被拦腰斩断。剪完，堆成一摞，编上号，完事。
听起来很荒唐吧？可这正是许多检索系统在把文档送入向量数据库之前，对它做的事——先肢解，再尝试理解。我一直对这件事耿耿于怀：我们究竟在用一个多么奇怪的流程对待信息？
当前围绕检索增强生成（RAG）的讨论中，一个反复出现的问题是：最佳分块大小是多少？256个词元？512？要不要让分块之间有重叠？在目睹足够多的检索翻车之后，我开始觉得，这根本就不是那个该问的问题。真正的问题不是“该在哪里切”，而是“所有文档是不是都该用同一种切法”。
设想有一份名为“速率限制策略”的技术规格，里面四个部分清清楚楚：为什么要有限速、算法怎么运行、一段代码示例、还有例外与边界情况。现在用固定大小的分块策略去索引它。标题落在一个块里，代码示例掉进另一个块，边界情况的解释又成了第三块。每个块被单独嵌入，变成向量空间里一个个孤零零的点。文字还在，但作为连贯意义单元的文档，已经消失了。
这时有人提问：“用户触发限速后会发生什么？”检索器精准地返回了包含代码的那个块。从它的视角看，一切完美：标识符匹配，嵌入向量很接近，相似度分数很高。但一件重要的事被丢掉了：解释这段代码属于哪一部分的标题在别处，说明算法为何这样设计的段落也在别处，所有的例外情况都在别处。模型拿到的是有效的代码，却被剥夺了让这些代码有意义的前因后果。它能说出函数干了什么，却解释不了整个系统为什么有那样的行为。
这引出一个核心观点：结构本身就是语义。很多人以为文档结构只是呈现形式上的装饰，我不这么看。一个标题告诉读者：下面所有的内容属于同一个想法。一个章节边界在说：这个思路到这里结束了。一个列表在说：这些条目应当被一起理解。这些不是视觉点缀，而是信息本身的一部分。当这些信号在索引过程中被抹掉，检索就丢失了人类阅读时几乎不会刻意觉察、却又全程依赖的线索。
于是我不再问“该怎样切分这份文档”，转而问：“最小的、还能独自保持意义的单元是什么？”有时它是一个段落，有时是整个小节，有时是代码块连同它上方那段解释，有时是一张图配它的说明。一份架构决策记录，往往只有在决策、理由和后果被作为一个整体时才有意义——就像一份技术规格，只有把“为何如此”“如何实现”以及“有什么坑”放在一起时，才能构成真正的认知。
固定的分块大小假设所有文档都是同质的，可现实中的信息从来不是豆腐块，不可能整齐划一地切完还保持原味。纠结于256还是512词元，就像在纠结该用多大的碎纸机来粉碎一本小说——越大残片保留越多，但该散的上下文照样散。真正需要的是倒过来想：先尊重文档的结构，再谈怎么存。毕竟，当一份规格书被剪成碎片，它的答案就只剩碎片，而我们却在抱怨大模型给不出完整答案——这多少有点黑色幽默。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
