《向量数据库指南》——AI应用长文本与RAG场景：搜索

场景：搜索

---

搜索场景的选择

• 这种选择大概率是出于成本等的考量，不能承担太高的推理成本的。因为搜索是商业服务，而不是慈善业务。

• 所以如果每一个免费用户都花几美金的成本去承担query的成本，这肯定是付不起的。所以背后一定是做了大量的优化，Perplexity 宣称做了一些小一点的模型，并单独为这个场景做了模型优化，这样它能够把成本降下来。

• 大家会觉得RAG 就是成本很低，但量大情况也不一定。如果使用的体量非常大的话，向量数据库本身的存储成本，还有进行服务 的serving 成本也是很高，也需要做一些优化。

• 比如Zilliz最近在做的冷热存储的切换，将价值不高、访问频次不高的数据放到冷存储里，以节省成本。如果用 RAG 都有成本的问题，那全都用大语言模型去付出高昂的推理成本，应该说在这些商业的产品里边一般是不现实的。

• 甚至刚才所说的coding场景成本下降都不一定很明显。举之前有客户疑问：Github Copilot 做的不错，是否拿长文本做的，"我把整个项目给丢进去了，然后我去问的时候，他这个回答的效果就很好，就是说他好像方方面面都照顾到了，那不就是长文本吗"。如果一个建库就需要超过 10 分钟，背后大概率是离线做了索引。当搜的时候，每一个 query的延迟，非常短，瞬间搜出来了，采用的技术一定不是长文本， 是结合了RAG的。Github Copilot的建库时间较长，单次搜索延迟很短，