场景:搜索
搜索场景的选择
-
这种选择大概率是出于成本等的考量,不能承担太高的推理成本的。因为搜索是商业服务,而不是慈善业务。
-
所以如果每一个免费用户都花几美金的成本去承担query的成本,这肯定是付不起的。所以背后一定是做了大量的优化,Perplexity 宣称做了一些小一点的模型,并单独为这个场景做了模型优化,这样它能够把成本降下来。
-
大家会觉得RAG 就是成本很低,但量大情况也不一定。如果使用的体量非常大的话,向量数据库本身的存储成本,还有进行服务 的serving 成本也是很高,也需要做一些优化。
-
比如Zilliz最近在做的冷热存储的切换,将价值不高、访问频次不高的数据放到冷存储里,以节省成本。如果用 RAG 都有成本的问题,那全都用大语言模型去付出高昂的推理成本,应该说在这些商业的产品里边一般是不现实的。
-
甚至刚才所说的coding场景成本下降都不一定很明显。举之前有客户疑问:Github Copilot 做的不错,是否拿长文本做的,"我把整个项目给丢进去了,然后我去问的时候,他这个回答的效果就很好,就是说他好像方方面面都照顾到了,那不就是长文本吗"。如果一个建库就需要超过 10 分钟,背后大概率是离线做了索引。当搜的时候,每一个 query的延迟,非常短,瞬间搜出来了,采用的技术一定不是长文本, 是结合了RAG的。Github Copilot的建库时间较长,单次搜索延迟很短,