RAG与上下文工程的讲解

一、RAG

1、什么是RAG？

**RAG（Retrieval-Augmented Generation）又称检索增强生成，**在大模型生成答案之前，先从外部私有知识库检索相关参考文本，将「用户问题 + 检索到的资料」一起送入大模型，模型依托真实资料输出回答如图：

2、RAG能够干什么？

让 AI 读懂你的私有文档售后规则、产品手册、合同、FAQ、内部资料上传知识库，AI 可以精准回答。你的场景：退款、发票、账号售后规则存入知识库，用户提问优先调取资料回复。
**解决大模型 "幻觉"（胡乱编造答案）**强制 AI 优先参考检索到的文档，减少凭空瞎说。
知识低成本更新 政策修改、新增售后条例，直接上传新文档，不用重新训练大模型。
长文档问答上千字手册、长篇协议，不用整段塞进提示词；只检索相关片段，节省 token。
私有化数据安全内部业务资料不上公网搜索，只在自有知识库查询，保护业务信息。

3、如何在coze中使用RAG？

（1）创建知识库

（2）创建工作流

【意图识别的配置】

【ping命令大模型配置】

【Python大模型配置】

【知识库检索】

（3）运行

二、上下文工程

1、什么是上下文工程？

要很好的理解上下文和上下文工程，我们还是得回到之前的提示词和提示词工程。
提示词（Prompt**）**：提示词是我们与 AI 模型沟通的"语言"。写好提示词，本质上是在学会如何清晰地表达需求。一个好的提示词需要包含：明确的目标、必要的背景信息、期望的输出格式。很多人觉得 AI"不好用"，问题往往出在提示词写得太模糊，此时就需要提示词工程来解决了。
提示词工程（Prompt Engineering）：正如我们之前所说，提示词工程不是玄学，而是一套系统化的方法论，如将提示词分为系统提示词和用户提示词，通过系统提示词来影响AI输出内容，这种通过系统提示词组合用户提示词，来引导大模型返回特定风格回复的做法，就是提示词工程
如图：

上下文：就是一次发给大模型的完整的历史记录。

上下文工程 = 研究给模型喂什么、什么时候喂、按什么顺序喂、哪些信息扔掉

2、如何管理上下文？

（1）3 类上下文区分

系统上下文：固定角色、规则提示词

业务上下文：RAG 知识库片段、Bing 搜索结果（单次问答临时）

对话上下文：历史聊天记录（多轮对话）

（2）在coze中可

•限制条数：查询消息列表 limit 设 5~8 条，不要拉全部历史；

•条件过滤IF选择器判断：消息列表不为空才带入历史；为空则不带；

•超长压缩（进阶）历史消息过多 → 先用大模型摘要关键信息，只把摘要放进 prompt，不塞完整聊天。