知识库类项目的第一个技术决策通常是：做检索增强（RAG），还是直接把资料塞进长上下文？

先看四个判断维度。

一、资料规模与更新频率：资料总量在几十万字以内、更新不频繁，长上下文足够；资料上万篇、每天新增，必须做检索，否则每次请求都在重复计费全量资料。

二、时效要求：法规、价格、库存这类必须实时的信息，靠训练或长上下文都不可靠，要走检索或直接查库。

三、可追溯要求：需要给出“依据出自哪份文件的哪一段”时，RAG 天然带出处，长上下文需要额外设计引用机制。

四、成本结构：长上下文每次请求都重复计费全部资料；RAG 每次只计费命中的片段，但有索引与召回的开销，还有维护成本。

多数生产系统最后是混合的：用 RAG 做粗筛，把命中的片段连同少量全局规则一起放进上下文。这样既控制了单次成本，也保留了完整的业务背景。

还有一个常被忽略的点：检索质量决定上限。切片策略、召回数量、重排模型这三项没调好，换再强的生成模型也救不回来。