RAG相比于传统搜广推

我在某厂RAG组做了一段时间，发现RAG(retrieval部分)本质上还是传统搜索那一套，比如indexing，query, ranking。那么相比于传统搜广推，RAG specific的技术难点在哪里？我唯一能想到的还是vector，基于vector的indexing，query都要复杂得多，数据量更大，latency挑战更多？

我问这个问题，主要因为感觉未来RAG需求越来越多，下次跳槽如果继续专注RAG领域，那么最具核心竞争力最有卖点的RAG skill是什么？

另外，RAG里最AI/ML的部分是？embedding generation? 其他的比如indexing，query感觉就是general infra

我觉得RAG跟search核心技术是类似的。但跟传统搜索不一样的是，RAG也会call llm e.g.最后一层有个llm summary。如果再搭配agent framework，是非常robust + user friendly的。RAG有很多方向且还需要努力的：1. multimodal; 2. Long context; 3. Responsible AI。这些每天都有很多paper发表，超多可以学的。
我觉得企业之所以重视RAG，是因为有domain knowledge，且这些domain knowledge并没有成为市面上任何LLM模型的训练数据，日后也不大会（企业肯定会更加保护）。

retrieval和reranking也是ml呀，只不过genai的部分主要在于embedding和generation，还有query processing。等agent ai来了以后就能做更多事情了。比如搜一个"5倍于美国平均售价的房子"，agent就能把任务分解成搜索均价，计算目标价格，生成相应的query。这是纯模式识别做不到的。

赞同楼主的rag和搜光腿的相似，只不过retrieve的对象变成了internal knowledge，多一个retrieval channel也是web scrape SERP API去搜外部信息。个人感觉最近RAG的趋势是Graph结构的知识库，增加cross chunk的召回。chunking部分anthropic提出了contextual embedding用小LM多加一个summary。还有更复杂的task routing，有些task会自己形成一个graph一样的workflow，这就需要不止一次调用LLM了，还需要LLM做planning

想象一下你有个问题想要知道结果，你可能会尝试不同的搜索关键字，每一次搜索结果你可能还得浏览好几个页面，然后综合考虑得到最终的你自己的答案。
传统的搜索只是其中的一步，针对一个查询给出排序好的结果。
llm rag的理想目标是可以自动化上面的完整步骤最终给出一个比较理想的结果。这里面随便哪一个深入一下都可以很复杂的。你自己提到的数据量，latency，回复质量，你觉得你的项目已经做到完美了？

同问呢。这种RAG可以理解成升级版搜光腿。我其实一直不太懂，搜光腿 vs AI，这算两个领域还是一个领域？

见仁见智。我不是很信rag。openai已经做了自己的rag，挤黄了好多初创公司。除非你们公司数据量很大，否自不用自己做。把文件上传就完了。我们组的工程师都不推荐rag，光vector database就要调好久。

rag是什么得缩写？