Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks 这个思路其实和之前的MemoRAG挺像的，只不过可能更简单一点？ 其实这里说的零检索延迟的代价就是所有的文档必须能够放到上下文窗口中。其实感觉是不太可用的，并且这里还没有做MemoRAG那样的压缩 唯一的优势就是节省prefill这一段计算开销了。确实在长上下文下耗时比较多，但这块可能还不是瓶颈，用户现在已经认同生成高质量的问答是需要时间的。所以相对来说…

在计算问题和文章相关性得分时，常见的几种方法（Bi-Encoder、Cross-Encoder、BM25、ColBERT）各有其特点。以下是它们的对比分析： 1. BM25（Best Matching 25） 原理：基于词频（TF）和逆文档频率（IDF）的统计模型，属于稀疏检索方法。 优点： - 速度快：适合大规模文档的快速召回（如百万级文档）。 - 无需训练：直接基于词频统计，无需标注数据或模型训练。 - 可解释性：得分基于词频和文档长度，结果易于理解。 缺点： - 语义缺失：无法捕捉同义词、上下文语义（如“苹果…

前几天看了港中深的graphrag，看到ToG实现的还相对挺复杂的，所以有兴趣再重新读一下ToG2的代码 基本思路从这里就可以看出来： * ToG1是让模型在图上自行探索，每次探索一跳的子图，然后让模型做prune实体/关系，最终得到结果 * ToG2相比于ToG1的点在于做entity prune的时候，会加上context来对entity打分。然后在每次reason的时候，也会带上这次得分高的chunk context 看实现的话，核心在： * para_rank_topk中，这里会把每个实体对应的chunk，…

代码结构 Chunk ChunkFactory.py，通过decorator注册chunking method * chunking_by_seperators * 定义了一些default text separator（如果希望自定义应该怎么做？传入不同的参数？) * chunking_by_token_size 有一个通用的DocChunk类，用来包装不同的chunking method。他会吃config中的chunk_method。 也负责做Chunk的存储和读取。 * build_chunks * 输入为…