RAG 踩坑总结
·
https://mp.weixin.qq.com/s/woFAkWRno6OxstLFzqm6aA
| 切割检索方案 | 核心操作思路（怎么做） | 最佳适用场景（什么时候用） | 使用代价/短板（注意点） |
|---|---|---|---|
| 重叠切割 | 切割文本时，让相邻的Chunk片段保留部分内容重叠，避免关键信息被截断丢失，是最基础的切割方式。 | 全场景通用，作为所有检索场景的基础兜底方案，无特殊格式和工具要求。 | 会轻微增加数据存储体量，无其他明显短板。 |
| 语义边界切割 | 不按固定字数机械切割，精准识别文本的句子、段落语义边界，在语义断开处进行分割，保证单块Chunk语义完整。 | 文档段落结构清晰、语句规整的文本，适合需要保证片段语义完整性的检索场景。 | 需要依赖NLP工具进行语义识别，无法纯手动简单实现。 |
| 句子窗口检索 | 先对文本做精细化拆分检索，命中关键内容后，额外扩展前后文本窗口，补齐关联信息，提升检索完整度。 | 对检索召回率、答案精准度要求极高的场景，需要精准抓取细节信息。 | 拆分后的碎片化Chunk数量多，整体数据存储成本大幅增加。 |
| 父子切割 | 采用「小Chunk检索、大Chunk返回」的逻辑：拆分极小片段用于精准匹配检索，检索成功后返回完整大块文本内容。 | 通用绝大多数场景，检索效果、性能、成本均衡，属于性价比最高的通用方案。 | 需要同时存储大小两种Chunk数据，存储量翻倍，索引结构更复杂。 |
| 命题化切割 | 依托大模型LLM，将长文本自主拆解为一条条独立、完整、无歧义的语义命题，以命题为单位做检索。 | 高精度知识库、核心重要资料、对内容准确性要求极高的业务场景。 | 全程调用LLM处理，模型调用成本高，耗时相对更长。 |
| Contextual Retrieval（上下文检索） | 文本向量化之前，通过LLM为每一个独立Chunk补充完整的全局背景上下文，消除单一片段的孤立感，再进行向量化检索。 | 文本语境关联性强、单Chunk脱离上下文易歧义、片段孤立感严重的文档场景。 | 产生LLM调用成本，可通过Prompt缓存技术大幅降低调用损耗、节约成本。 |
https://mp.weixin.qq.com/s/LlEhKelo_sfZlEzHodyymA
https://mp.weixin.qq.com/s/vaLJD2ndpy6Ahfb-LjU5KQ
研究表明，上下文越长，模型表现越差。
原因在于，LLM 不得不在大量与当前问题无关的“噪声”中管理信息。这个现象叫 “迷失在中间”（Lost in the Middle），模型会丢失埋在上下文中间的重要信息。
Claude Code 的工具搜索是懒加载：工具存在于 Agent 的世界里，当上下文压力越过一个阈值时，就按需加载。这个决策发生在 Agent 循环内部，在请求已经到达之后。是模型自己决定要搜索什么。
Gateway 的语义过滤器则不同，它是前置预过滤：LLM 根本就收不到其他那些工具。这个决策完全发生在 Agent 循环之外，在基础设施层，在请求到达 LLM 之前。
Gateway 不是让模型自己去搜索工具，而是把一个精挑细选的、预先过滤好的工具集交到它手上。这不仅省了 Token，更确保了模型永远不会在内部搜索循环里失焦。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
5
0- 0
已为社区贡献3条内容
所有评论(0)