大模型集成与 RAG
大模型集成，指的是把语言模型接到你的数据和产品上，让它依据你实际掌握的知识作答，而不是依据它训练时记住的内容。在实践中这就是检索增强生成（RAG）：找到正确的上下文，交给模型，并标明答案的出处。大部分工程投入花在检索质量上，而不是那一次模型调用上。
RAG 的成败取决于检索
如果正确的段落没有被检索出来，再好的模型也答不对。团队通常是在埋怨了模型好几个月之后，才发现这一点。
- 分块要尊重文档结构，而不是按固定长度一刀切。
- 混合检索——关键词与向量并用，因为精确词项依然重要。
- 在候选集进入模型上下文之前先做重排序。
- 对检索单独度量：正确的那个段落，究竟有没有出现在结果前列？
让输出能被程序安全使用
返回散文的模型，用在聊天窗口里没问题，但作为系统其余部分的输入就毫无用处。当输出要喂给代码时，它必须是结构化且经过校验的。
- 受 schema 约束的输出，在被下游消费之前先完成校验。
- 对模型拒答或返回不可用内容的情况，做出明确处理。
- 回溯到源文档的引用，让用户可以自行核实这个说法。
- 当那个「自信的答案」还不足以上线时，提供确定性的兜底方案。
让索引保持新鲜
随着底层文档变化，检索系统会悄无声息地衰退。我们把数据接入管道当作系统的一等公民来构建——增量更新、删除处理，以及一种能判断索引有多陈旧的手段——因为一个源自已删除文档、却答得信誓旦旦的错误答案，比没有答案更糟。
常见问题
- 用大白话说，RAG 是什么？
- 检索增强生成：在作答之前，系统先在你的文档中搜索相关段落，并把它们放进模型的上下文里。模型随后依据这些材料作答并注明出处，而不是依赖它在训练时记住的东西。
- 它能用我们的私有数据作答，同时又不让这些数据去训练模型吗？
- 可以。检索是把你的数据放进请求里，而不是放进模型的权重里。至于服务商是否留存请求数据，取决于服务商与你所购买的套餐——这属于合同问题，我们可以在你正式承诺之前帮你核实。
- 我们该用哪个向量数据库？
- 对多数负载来说，PostgreSQL 加 pgvector 就够用，还能少运维一个组件。专用向量数据库要到规模很大、或过滤条件很苛刻时才开始显出价值。我们更倾向于等你的数字确实撑得起它时再引入。
- 我们怎么知道检索有没有起作用？
- 把它和生成分开来度量。我们会构建一组已知正确出处的问题，追踪这些出处是否出现在检索结果中。这个数字会告诉你该往哪儿投入——大多数时候是检索，而不是模型。