最近对rag的一些想法和实践

问题描述：

去年这会儿，大家都在搭rag，从dify, coze到ragflow，但是经常会遇到一个问题，demo好整，但是效果嘛，不好说。现在已经有一些解决方案，比如用easydataset做qa对，用Hyde扩展回答的范围，用RAG去扩展问题的范围。但是还是有一个我认为不能理解的，那就是向量相似度不等于语义相关性。如果不做qa对，仅仅按chunk切分，会导致什么问题呢，三重语义断裂——代词指代丢失、跨句依赖断裂、术语定义分离。更恼火的还有，Embedding导致的多个不确定的方面：比如模型选择、分块策略、相似度阈值导致相同的查询返回不同的结果。现在其实也有很多项目已经认识到这点，抛弃embbeding，比如：pageindex，sirchmunk，tree-search等等等，我研究了这些agentic+no embbeding的方案，然后有了一些自己的想法和实践。

解决之道是Agentic RAG范式转换：把语义理解还给LLM，检索系统只负责提供确定性结构。
以下是具体的实现方法和路径：
用SQLite+FTS5替代向量数据库，保留文档原始层级（章节-条款-段落），通过BM25关键词匹配+迭代收敛算法（自动调整查询词直到命中2-3篇核心文档），让LLM像查阅目录般精准导航。同时保留检索路径，这样整个过程完全可审计，每次查询轨迹都有完整记录。
这套机制的工程价值在于：零外部依赖、单人可维护（确定性代码易调试）。很适合法规合规、企业SOP、医疗指南等需要"精确溯源"的场景。

核心思想是信任LLM的理解与推理能力——不需要系统替它猜答案，只需要系统可靠地帮它找到内容。
注意：这个技术方向不是通用的，对于实时对话要求很高的来说，不太适用。
实践项目在这里：yang478/auditable-knowledge-packs
使用方法，放在skills下，用LLM来进行知识库skills的构建，再用该skills问问题就可以了。