如果你的客户问“这个产品现在还能退吗? ”，系统可能需要查看公开网页、内部规则，还要知道用户上一句话说的是哪个订单。很多方案把这些能力统一写成“给大模型增加知识”，实际开发时却是三条不同的数据链路。
联网搜索解决公开信息的新鲜度
搜索适合查公开且经常变化的内容，例如新版本文档、新闻和公开价格。应用发起搜索，把结果交给模型整理。它的风险也很明确：网页可能过期、互相矛盾，搜索摘要还可能缺少关键条件，还有你可能不知道它采用的是哪个互联网"天才"的输出。
所以模型给出答案时我们要保留来源 URL、抓取时间和关键片段。涉及付款、法律或安全决策，不能因为结果排在前面就自动相信。
在百炼的 OpenAI 兼容调用中，enable_search 属于平台扩展参数，Python SDK 需要通过 extra_body 传递。它不是所有 OpenAI 兼容服务都支持的标准字段。
RAG 解决受控资料的检索
RAG 是 Retrieval-Augmented Generation，即检索增强生成。应用先从指定知识源检索相关片段，再把片段和问题一起交给模型。退款规则、产品手册和内部流程更适合这条路，因为资料范围和更新流程可以由应用控制。
一套能用的 RAG 不只是“文件切块后放进向量库”。至少要处理：
- 文档版本和生效日期；
- 用户是否有权看到命中的片段；
- 检索结果是否真的回答问题；
- 答案能否回到原文位置；
- 没找到证据时是否明确拒答。
Embedding、向量检索和重排只是中间步骤。最终目标是给答案提供可检查的依据。
记忆解决当前用户的连续性
对话历史告诉系统“这个产品”指什么，也能保存用户选择的语言或输出格式。模型服务通常不会替你的应用永久保存任意历史；应用需要在请求里带回相关 messages，或者从外部存储召回摘要。
记忆不应变成无限累积的聊天记录。保存什么、保存多久、谁能删除，以及敏感信息是否允许进入模型，都要由应用决定。对当前任务无关的旧信息应当舍弃，否则只会增加 Token 和错误关联。
用四个问题选择
面对一个数据需求，可以先问：
- 信息来自公开互联网，还是受控资料？
- 内容多久变化一次，谁负责更新？
- 不同用户看到的内容是否不同？
- 答案需要引用来源，还是只需要保持本轮对话连续？
“今天公开发布了什么”偏向联网搜索；“当前有效的内部退款规则”偏向 RAG；“用户刚才选的是哪一笔订单”属于对话记忆。一个真实请求可能同时使用三者，但每条数据都要带着来源、权限和生命周期进入系统。
验收不要只看回答像不像
准备一组带答案和来源的测试问题，分别检查搜索命中、知识库召回、权限过滤和历史指代。故意加入没有资料的问题，确认系统会说“没有足够依据”，而不是补出一个听起来合理的规则。
下一篇进入 Function Calling。模型可以建议调用哪个工具，但参数校验、权限确认和实际执行仍然是应用的责任。