向量数据库的正确用法是什么？

[sillydaddy]

想用它预处理文档，然后帮助提取与关键字匹配的内容。看起来很理想，但实际提取不尽人意。

我做了个小工具，把切分后的每段，与关键字的匹配程度，可视化出来了，可以直观看到匹配度。

从网页内容中，提取“中国人民银行的编制”，效果不错：


从网页内容中，提取“中国人民银行的职责”，开头匹配的很好，但漏掉了接下来的那些：


可以看到，在提取“中国人民银行的职责”匹配的句段时，会漏掉枚举的那几条。

这可以说是段落拆分的问题，我是逐句拆分的，问题是，段落怎么才能合理拆分呢？如果必须知道哪些跟哪些是在一起的，那就相当于已经提前理解文章的内容了，就没有必要上向量数据库了。

所以，向量数据库如何做是比较合适的呢？就比如我上面的这种应用场景。

[IsaacYoung]

没太研究过，不过记得之前好像看到过几个方向，楼主可以参考下：
1. 分段的时候不要完全分割开，上一段和下一段保留一部分重叠
2. 用语义分割，印象中好像是根据文本的结构例如段落、标题等进行分割

[cryptovae]

400 个 token 一段的情况下，上一段的后 50 个 token 和下一段开头的 50 个 token ，一起算向量，连贯性有了
每个段落都有自己的 metadata ，包含标题，章节，目录名称，都可以拿来计算向量
通过 LLM 提取时间线和关键词计算向量，可以增强相对应的语义检索

[sillydaddy]

@IsaacYoung
@cryptovae
这些方法应该能缓解，但是没有从根儿上解决。比如，如果恰好关键信息不在重叠的 token 里面呢？

关键在于，向量搜索它会漏掉。

如果是人来交互式的查看结果，可以把最匹配的 topK 个，优先展示出来，如果不满意，再动态增加 topK 。
可如果是程序来处理呢？怎么保证不会漏掉呢？

[IsaacYoung]

@sillydaddy 看看这个 AI 的方案 https://gemini.google.com/share/04a576897525

[fennu2333]

同语言搜索用向量 + BM25 混合搜索效果会更好些，根据你的目的调整权重。向量搜索也不是银弹，他只能解决 query 和 chuck 之间向量表征相似度的问题，还是要看你具体场景看怎么切 chunk ，如何加入更多的召回手段进行多路召回

[maolon]

实际我觉得是关键字匹配的问题，关键字匹配本身是 sparse 匹配任务，对应的应该是 tfidf 这种算法搞出来的向量，但是你用的这种 embedding 模型生成向量是 desnse 的，换言之就是关键字那边语义信息不足，

正常做法应该是问题改写，也就是从你的关键词里改写出多个问题（比如加入上下文 context 然后改写），再来匹配，或者反向操作，直接用 bm25 来处理文本片段

[sillydaddy]

@IsaacYoung 感谢分享，里面提到的「父子文档」，其实跟楼上提到的依赖预制的语义结构是一样的。这个依赖条件，其实本身也需要 LLM 的介入，否则只凭借解析文本的结构、网页的结构来确定，并不稳定。

所以，感觉还是需要 LLM 的理解能力来介入，提取多层的抽象信息。但这里有个悖论，如果是整理出的知识，需要多次检索，那 LLM 介入一次，后续多次使用，效率比较高。但如果是我这种，只需要提取一次，那直接让 LLM 提取所需的信息就可以，就没必要再让向量数据库转一次手了。

前者抽取多层抽象信息，感觉跟我之前提到的笔记的网状 tag 系统，不谋而合了： https://v2ex.com/t/825142

[cuimc]

我最近在使用 llm wiki 的形式在做，感觉还不错

[Morriaty]

这个悖论，它的发展历程其实就是 cursor 类以 RAG 向量匹配为核心的 CodingIDE ，逐步过渡到 ClaudeCode 类以 ReACT 多工具（ grep, ls, find, mcp 等）为核心的 CodingAgent 的过程

所以，理论上你这个中国人民银行的查询要搞好，最快的方法是接个 CC ，和一些工具函数

[sillydaddy]

@maolon #6 这个把关键词改写成长句的，还是第一次见到，应该是叫 HyDE 吧，还挺神奇的！我感觉挺适合我的需求的，感谢！

[sillydaddy]

@Morriaty 你的意思是不是，让大模型自己根据搜索匹配的过程，来适应性的查找？比如搜索到某些关键字，然后再扩展它的范围？也很道理。因为我的目的就是节省 token ，如果不用读全文，那就满足我的需求了。

[nomagick]

你的颗粒度太细了，你是想在一篇文章里找出和查询最相关的句是吗？ 这就需要在句向量里包括之前的上下文信息，关键词 late chunking , 通俗来讲就是每个句子的向量不是它自己，而是整篇文章截止到句子结束。

如果是想在海量文档里找出相关文档，那就按篇章段分片，不要拘泥于句向量。

[sillydaddy]

@nomagick 对了，补充一下这件事的背景，其实我在做一个 govmap 项目，需要搜集国省市县乡的各机构的职责、构成、编制等等：
https://v2ex.com/t/907899#r_12559610

涉及到的文档处理比较多，需要不少的搜索工作量和整理工作量。还是希望能尽量减少一些 token 的消耗。所以，需要一个比较流程化的处理过程，比如搜索、下载、抽取关联片段、提取信息、整理为格式化数据。

[nomagick]

@nomagick Late chunking 不是所有模型都能支持，需要 mean pooling 的模型才可以

[sillydaddy]

@nomagick @sillydaddy #13 当然也不止这一个项目。而且我感觉所有需要从互联网收集、整理信息的，都会遇到类似的需求：不能漏掉关键信息，不能消耗太多 token 。

[nofishing]

@sillydaddy #13 这个需求过去是由数据清洗、建模、检索多个数据团队互相配合做的工作，光靠通用 RAG 和 AI 效果肯定不能让人很满意

[PiersSoCool]

重叠一点，然后召回多一点，就好了，成本我建议你直接用 deepseek 就好了，便宜的很

[PiersSoCool]

如果有很多关系，估计要知识图谱了

[PiersSoCool]

暴力一点，检索的时候，召回全文给 llm ，也没有多少钱的

[Clannad0708]

@IsaacYoung #4 重点在于你怎么把你以为的“不满意” 可以量化的表示出来。

就好比模型训练的时候，输入给她的不是英文单词不是汉字，而是根据 embeding 后的向量表-才能被拿去计算，才能被算法计算相似性。

你想要让他做的很好就一定要把握好所谓展示所谓满意的标准是什么，如果只是人为的无法用逻辑和算法表示的话，那确实没办法了。