


1 IsaacYoung 1h 21m ago 没太研究过,不过记得之前好像看到过几个方向,楼主可以参考下: 1. 分段的时候不要完全分割开,上一段和下一段保留一部分重叠 2. 用语义分割,印象中好像是根据文本的结构例如段落、标题等进行分割 |
2 cryptovae 1h 2m ago 400 个 token 一段的情况下,上一段的后 50 个 token 和下一段开头的 50 个 token ,一起算向量,连贯性有了 每个段落都有自己的 metadata ,包含标题,章节,目录名称,都可以拿来计算向量 通过 LLM 提取时间线和关键词计算向量,可以增强相对应的语义检索 |
3 sillydaddy OP @IsaacYoung @cryptovae 这些方法应该能缓解,但是没有从根儿上解决。比如,如果恰好关键信息不在重叠的 token 里面呢? 关键在于,向量搜索它会漏掉。 如果是人来交互式的查看结果,可以把最匹配的 topK 个,优先展示出来,如果不满意,再动态增加 topK 。 可如果是程序来处理呢?怎么保证不会漏掉呢? |
4 IsaacYoung 32 mins ago @sillydaddy 看看这个 AI 的方案 https://gemini.google.com/share/04a576897525 |
5 fennu2333 19 mins ago 同语言搜索用向量 + BM25 混合搜索效果会更好些,根据你的目的调整权重。向量搜索也不是银弹,他只能解决 query 和 chuck 之间向量表征相似度的问题,还是要看你具体场景看怎么切 chunk ,如何加入更多的召回手段进行多路召回 |
6 maolon 19 mins ago 实际我觉得是关键字匹配的问题,关键字匹配本身是 sparse 匹配任务,对应的应该是 tfidf 这种算法搞出来的向量,但是你用的这种 embedding 模型生成向量是 desnse 的,换言之就是关键字那边语义信息不足, 正常做法应该是问题改写,也就是从你的关键词里改写出多个问题(比如加入上下文 context 然后改写),再来匹配,或者反向操作,直接用 bm25 来处理文本片段 |
7 sillydaddy OP @IsaacYoung 感谢分享,里面提到的「父子文档」,其实跟楼上提到的依赖预制的语义结构是一样的。这个依赖条件,其实本身也需要 LLM 的介入,否则只凭借解析文本的结构、网页的结构来确定,并不稳定。 所以,感觉还是需要 LLM 的理解能力来介入,提取多层的抽象信息。但这里有个悖论,如果是整理出的知识,需要多次检索,那 LLM 介入一次,后续多次使用,效率比较高。但如果是我这种,只需要提取一次,那直接让 LLM 提取所需的信息就可以,就没必要再让向量数据库转一次手了。 前者抽取多层抽象信息,感觉跟我之前提到的笔记的网状 tag 系统,不谋而合了: https://v2ex.com/t/825142 |
8 cuimc 9 mins ago 我最近在使用 llm wiki 的形式在做,感觉还不错 |
9 Morriaty 1 min ago 这个悖论,它的发展历程其实就是 cursor 类以 RAG 向量匹配为核心的 CodingIDE ,逐步过渡到 ClaudeCode 类以 ReACT 多工具( grep, ls, find, mcp 等)为核心的 CodingAgent 的过程 所以,理论上你这个中国人民银行的查询要搞好,最快的方法是接个 CC ,和一些工具函数 |