RAG 有什么比较有前景的工程运用嘛？

卢娜说：客服、医疗、生产、制造等可以依赖过往内容进行总结并重新创作的文本类回答。都能做。

能做是能做，怎么做好是另外一个问题。

医疗：当前病人历史病例作为上下文，来帮你分析你的所有问题，都离不开病人历史问题，甚至可以联想即将可能发生的病症。

生产、制造：数控机床代码生成，一个小时的活给你 5 分钟生成好，自己检查就行（不能完全信任 AI ）

合同审查、法规条文解读、财务快速制表等等等等。看你能想到什么。


还记得什么 17 岁高中生 ai 识别食物卡路里的新闻么，那不就是 rag 么，用户输入的图片不就是过往数据么。

你能不能做个拍照识别配料表的小程序给老人用呢。

我始终觉得这是一个中间形态，只是因为现在 LLM 还不够强

@rogerer RAG 想要解决的是 LLM 幻觉的现有技术难题，如果有可信的信息来源，LLM 幻觉问题将能够被很大程度上解决。

个人认为，除非 LLM 完全抛弃自回归，否则 RAG 将永远存在。

@AlghaPorthos 幻觉问题可以通过 Knowledge Edit 解决。我并不太同意 RAG 可以解决幻觉，RAG 能做的只是给 LLM 添加一些提示信息，一方面 RAG 本身可能会引入错误信息，另一方面，提示信息并不能避免幻觉的出现，比如在长程推理场景下，RAG 输入的提示信息会被稀释。

另一个 RAG 目前试图解决上下文长度不够的问题。

我认为我们对上下文的需求是有极限的，比如 context window 已经能装下一整个 codebase 了，追求更长的上下文的意义就没那么大。

此外我们还有一些特别的技术比如 context compression 我认为这是比 RAG 解决 context length 更好的方案。