1. 数据入向量库
企业里的知识不会乖乖地以纯文本形式等着你。PDF、Word、PPT、网页、Markdown、数据库，什么都有。光是把这些东西解析成干净的文本，就是一堆脏活累活。PDF 里的表格、扫描件、双栏排版，每一个都是坑文档要切成小块才能检索，但切多大是个问题。切太大，检索不精准，一大段里可能只有一两句话有用；切太小，上下文信息丢了，检索到的片段看不懂在说啥。
2. 问题重写
用户输入的问题，往往不能直接拿去检索。
口语化：用户问“报销咋整”，你拿这四个字去做向量检索，效果能好吗？得把它展开成“公司报销流程是什么，需要准备哪些材料”之类的完整表述，检索效果才会好。
多轮对话：用户第一轮问“年假有多少天”，第二轮接着问“怎么申请”。这个怎么申请单独拿去检索，系统根本不知道在问啥。得把上文的年假补进去，变成年假怎么申请，才能检索到正确的内容。
多意图：“请假流程是什么，另外帮我查下我还剩几天年假”——这其实是两个问题，一个要检索知识库，一个要查业务数据。你得先把它拆开，分别处理。
复杂问题：用户问“我想申请调岗到上海，需要满足什么条件，流程是什么，大概要多久”——这个问题涉及多个方面，可能散落在不同的文档里。直接检索未必能覆盖全，拆成几个子问题分别检索，再合并答案，效果会更好。
问题重写这一步，本质上是在弥补用户表达和检索需要之间的 gap。做不做、做多深，直接影响后面的检索质量。
3. 意图识别
用户发来一句话，系统得先判断：这句话想干嘛？不是所有问题都需要走 RAG 流程。
闲聊：用户说“你是ChatGPT么？”，这种情况去知识库里检索，能检索出什么？这种情况应该直接让模型回复，不用走检索。
工具调用：“报销制度是什么”需要检索知识库，“我这个月的报销单到哪一步了”需要调用业务系统接口。走错了路，答案肯定不对。
多知识库路由：企业里可能有多个知识库——HR 政策库、产品文档库、技术文档库。用户问的问题应该去哪个库里找？如果每个库都搜一遍，成本高、噪音大；如果只搜一个库，选错了就什么都检索不到。
该不该回答：有些问题不该回答。涉及敏感信息的、超出系统能力范围的、恶意试探的，都需要识别出来，给出合适的拒绝或引导。
意图识别做得不好，后面的流程再完美也没用——方向错了，跑得越快错得越远。
4. 数据检索
这是 RAG 的核心环节，也是最容易出问题的环节。
向量检索的局限：纯向量检索对语义相似性很敏感，但对精确匹配很弱。用户问“BRD-2024-0312 这个需求的状态”，这是个精确的编号，向量检索可能完全找不到。类似的还有人名、产品型号、订单号这些，光靠向量不够。
混合检索的取舍：为了弥补上面这个问题，通常会把向量检索和关键词检索结合起来。但两边的结果怎么融合？权重怎么设？不同场景可能需要不同的策略。
top-k 选多少：检索返回多少条结果？选少了可能漏掉关键信息，选多了塞给模型一大堆内容，它可能反而被干扰。而且返回越多，后续处理的成本也越高。
结果重排序：向量相似度高的，不一定是最相关的。很多时候需要再加一层重排序（Reranking），用更精细的模型对检索结果重新打分排序。这一步能明显提升最终效果，但也增加了延迟和成本。
召回了但不该用：检索到的内容不一定都该用。有些可能是过时的版本，有些可能相关度其实不够，有些可能用户没有权限看。在塞给模型之前，还需要做一轮过滤和筛选。
5. 会话记忆
单轮问答相对简单，多轮对话的复杂度会陡增。
上下文要带多少：用户聊了 20 轮，你把所有历史对话都塞给模型？Token 成本扛不住，模型也容易被早期不相关的内容干扰。但如果只带最近几轮，又可能丢失重要的上下文信息。
记忆的压缩和摘要：一种做法是对历史对话做摘要，提取关键信息，用摘要代替完整的历史记录。但摘要过程本身可能丢失细节，摘错了后面就全错了。
长期记忆：有些场景需要跨会话的记忆。用户上周问过的问题，这周再来的时候系统还能记得。这涉及到记忆的持久化存储和检索，又是一套单独的机制。
记忆的更新和遗忘：用户在对话中纠正了之前的信息，系统得能更新记忆。有些过时的信息需要遗忘，不能一直带着。这些都需要额外的逻辑来处理。
6. 其他功能
除了主流程，一个完整的 RAG 系统还需要处理很多边边角角的事情。
引导澄清
用户的问题太模糊，没法检索，也没法回答。比如用户就说一个“报销”，系统应该反问：你是想了解报销流程，还是查询报销单状态，还是想提交新的报销？这需要系统能识别出问题不够明确，并给出合适的引导。
请求风控
总有人会试图让系统说一些不该说的话，或者套取敏感信息。需要在入口处做一层过滤，识别并拦截恶意请求。同时如果知识库资料包含公司隐私数据，需要部署本地大模型，对应的限流风控也需要做。
停止生成
用户发现答案不对，想中断重新问，系统得能响应停止指令，及时终止生成，不要傻傻地继续输出。
模型负载均衡
线上流量大的时候，单个模型实例扛不住。需要有负载均衡机制，多个模型实例之间分配请求。如果用的是第三方 API，还要处理限流、降级、多供应商切换等问题。
答案溯源
用户看到一个答案，想知道依据是什么。系统需要能标注出答案来自哪个文档的哪个部分，让用户可以点进去查看原文。这对于建立信任、方便核实很重要。
效果监控和反馈收集
系统上线后，怎么知道答得好不好？需要有机制收集用户的反馈（点赞、点踩、纠正），监控各个环节的指标，为后续优化提供数据支撑。
提示词结构的五个要素
角色 任务 约束 输入 输出