Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
但 RAG 也很麻烦。切块、向量、rerank、权限,全是坑。
所以不是 RAG 必须上,是任务决定。几十页临时合同可以长上下文,几万份制度肯定要检索。
长上下文不是越长越聪明吗?
不是。长上下文只代表窗口更大,不代表模型会稳定关注每个细节。位置、重复、冲突内容都会影响答案。
我们试过把整本手册塞进去,模型会引用旧条款,因为旧条款也在上下文里。
这叫上下文污染。不是资料越多越安全,过期资料混进去更危险。
那怎么判断放多少?
先按任务放。用户问报销流程,就不要把入职、采购、绩效都塞进去。
我现在做法是:检索召回一批,rerank 留少量,再把文档标题、更新时间、权限一起进上下文。
那长上下文主要适合什么?
适合长文总结、合同审阅、代码仓库片段阅读、会议资料综合。前提是资料集合本身可控。
还有一点:长上下文贵。能用 8k 解决的问题,不要硬上 200k。
你好!看起来您对这段对话很感兴趣,但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。
有了你的建议,这篇帖子会更精彩哦 💗