时间顶得住吗？钱包顶得住吗？
知识库一旦大了起来，每次查询都要把查询文本和所有文本比对一遍
你猜为什么业界大部分都用嵌入而不是完整上下文？这完全就是一个道理，无非就是把一次变成多次了而已
1 Like
首先，如果不用推理模型的话，直接回答的效果远比嵌入模型差，并且你分开来提取是否有用的话你根本没办法对相关性排序，实际效果肯定远比常规 RAG 差
其次，你要考虑成本，如果用推理模型的话，100 M 的知识库回答一次就需要 $100（Gemini 2.5 Flash）？你能接受这个成本吗？甚至由于查询文本不同，你根本没办法进行输入缓存，一次请求里处理输入和输出的时间就长达 10 分钟，而且一定会被限制高并发，那现在一两个小时回答一个普通 RAG 几秒钟就能回答的问题，而且效果还没有专业的嵌入模型好，你能接受吗？
1 Like
你为什么会觉得2.5 flash是小模型，比较笨？这玩意至少五千亿参数，各种排行榜上很靠前
这玩意有点类似，还比你想得靠谱得多，它是按attention算相似度的，相似度是可解释的、可量化的
但是这篇仍然是故事汇，至少它公开的库和embedding可靠性和效果差远了
用楼主的办法的话llm调用少了大海捞针测试（Needle-In-a-Haystack）效果会惨不忍睹，估计除了首尾都要零分了。调用多了成本爆炸，远远高于embedding，速度还非常慢
这个就是 context engineering ，的面向方法，但这个往往是重点解决 上下文带来的扭曲的
一般来说，用子 LLM ，做搜索 需要比 RAG 有一点优势才行
比如最近的 Anthropic 的 How we built our multi-agent research system，就提到 多LLM 带来的效益，但这个是因为，子LLM + search tool 带来的，，因为每个都有独立的上下文 去执行搜索，不单效果好 ，还效率高（可以parallel），当然团队也发现，这样做有很多难点，必然如何分配任务的问题（搜索的深度和广度 都是灵活的）
好像DeepWiki在你提问时就是这么做的
DeepWiki/OpenDeepWiki 好像用的是混合检索吧？（嵌入+关键词搜索+重排）
这个也是RAG的一种，只是不用embbeding模型了，RAG就是召回相关内容，至于用什么召回都可以
楼主说的这个我之前也考虑过，但是我之前想的是让模型用 Python 去在文档里搜索它想要的关键字，然后自动扩展上下文，以达到一种接近检索的效果。
怎么确保小模型的描述正确
这是没办法的，小模型描述可能出现的错误
嵌入召回可能不准，但是不影响，因为你用来跑RAG的这个大模型一般都是很好的模型，即便是找到了错代码，也可以分辨出来，不会用，或者换词重新查