上下文压缩
当做完知识库检索后，返回来的内容虽然匹配度比较高，但是这并不代表质量就很高可以拿来给agent生成内容了。RAG返回的检索内容通常都会包括以下问题：
-
相关但不必要的信息（一个文档块里只有一点点内容匹配到，但是由于返回的都是文档块，会返回很多无用的内容）
-
完全无关的噪声（检索器误召回）
-
重复信息（返回了多个块但是讲的实则还是同一个概念）
如果我们不处理直接把几百个块拼进 prompt，会导致：
-
上下文窗口爆炸：即使是模型的上下文窗口有128k 也会被撑满，成本飙升。
-
注意力稀释：LLM 需要在大量噪声中找信号，容易忽视真正有用的部分。
-
幻觉风险：噪声中的错误信息可能被 LLM 当成事实。 我们平时在各大平台使用模型时，如果有看深度思考的内容的话，有时候在经过很多轮问答后，会出现一个"正在压缩上下文内容"的标识，这样做的目的是保留检索文档中与查询最相关的信息，一般会用以下这三种方法：
-
用一个小模型（比如BERT)给每次Q&A或者每个句子打分，只保留高分的句子，适合在与模型交流、梳理知识点时用
-
用一个语言模型（比如 GPT-3.5）直接生成针对查询的总结。
-
把检索结果中与当前任务最相关的部分增强比重，这样做比较适合在解决一个个任务时，让模型动态检索需要哪些内容
总的来说，压缩这一步主要是为了避免检索到的文档里，内容参差不齐和噪声多的问题
知识库更新
我们之前提到，HNSW不能每种情况都用的其中一个原因就是因为知识库更新时，节点删除后会留下一个"僵尸节点"污染图结构，维护的成本会很重。
那么如果真的要维护的话（毕竟不管怎么样，维护的核心逻辑不会变），比较常见的是构建双索引并定期重构索引：构建一个主索引一个增量索引，主索引的内容比较全，且更新频率比较慢，每周或每月更新一次；增量索引则负责存储新增或者修改的内容，可以实时更新。然后在查询时合并两个索引的结果再去重，这样就可以保证搜索到原来的内容的同时，还能搜索到更新后的内容。
不过这样做的缺点是增量索引更新时不一定能真的做到实时同步，有延迟，但是实际应用时依然会这么做，理由很简单，只需要把控好更新的时间点，比如放在半夜或用户少的时候，我们有时候看到的停服更新就是这个道理