三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

AI应用工程化：Workflow、RAG、记忆治理与幂等性四大核心实践

发布时间：2026/8/8 5:17:53 三亩地 编程学习日记
AI应用工程化：Workflow、RAG、记忆治理与幂等性四大核心实践

1. 项目概述：构建稳健AI应用的核心支柱

最近和不少做AI应用落地的朋友聊天，大家聊得最多的不再是“哪个模型效果最好”，而是“我的应用怎么老是出幺蛾子”。比如，一个简单的客服问答，用户问同一个问题，第一次回答得挺好，第二次就答非所问了；又或者，一个处理文档的自动化流程，跑着跑着就卡住了，或者重复提交了订单。这些问题，往往不是大模型本身的能力问题，而是我们构建应用时，忽略了那些“不起眼”却至关重要的工程化基石。

今天，我们就来深入聊聊AI大模型应用开发中，决定系统是否可靠、可用、可维护的七个核心工程概念。我把它们总结为：Workflow（工作流编排）、RAG（检索增强生成）、记忆治理，以及幂等性。这四者，加上智能体（Agent）、评估（Evaluation）和部署运维（Deployment & Ops），构成了支撑一个高质量AI应用从原型走向生产的“七根支柱”。这篇文章，我会聚焦前四个，结合我趟过的坑，掰开揉碎了讲清楚它们是什么、为什么重要，以及具体怎么落地。

简单来说：

  • Workflow解决的是“如何让多个AI步骤和工具像流水线一样自动、有序、可靠地运行”。
  • RAG解决的是“如何让大模型突破自身知识局限，准确、实时地回答特定领域问题”。
  • 记忆治理解决的是“如何让AI记住关键的对话历史，同时避免记忆混乱、泄露或无限膨胀”。
  • 幂等性解决的是“如何确保同一个用户请求，无论执行多少次，结果都一致且安全”。

听起来都是偏后台、偏工程的概念，但它们直接决定了前端用户体验是“惊艳”还是“惊吓”。下面，我们就一个个拆解。

2. 核心概念深度解析与设计思路

2.1 Workflow：从脚本到自动化引擎的跃迁

早期我们调用大模型API，可能就是写个函数，发送prompt，拿到回复，结束。这只能算一个“脚本”。但当你的应用需要串联多个模型调用（比如先用一个模型分析用户意图，再用另一个模型生成SQL查询数据库，最后用第三个模型润色结果），或者需要混合调用外部工具（搜索API、计算器、代码执行器），甚至需要根据中间结果做条件分支判断（如果分析结果是A，就走流程X；如果是B，就走流程Y）时，一堆if-else和函数调用堆砌的代码很快就会变成“屎山”。

Workflow（工作流编排）就是为了解决这个问题而生的。它的核心思想是将复杂的AI应用逻辑，抽象成一个个可复用、可可视化、可监控的“节点”和“边”。节点代表一个原子操作（如调用LLM、执行Python代码、调用API），边代表数据流或控制流。

为什么必须用Workflow，而不用普通代码？我总结有三个关键原因：

  1. 可维护性与可视化：一个复杂的业务逻辑，用代码写可能几百行，逻辑嵌套深，新人根本看不懂。而用Workflow工具（如Dify、LangChain Expression Language、甚至像Node-RED这样的低代码工具）画出来，整个数据处理脉络一目了然。哪个环节出错，可以快速定位。
  2. 稳定性与错误处理：好的Workflow引擎内置了重试、降级、超时、断路器等机制。比如，调用一个外部搜索API失败了，可以自动重试3次，如果还不行，就跳过这个节点或使用缓存数据，保证主流程不崩溃。这在裸写代码里实现起来非常繁琐。
  3. 协作与复用：团队可以将一个验证过的“用户意图识别”子流程打包成一个组件，其他项目直接拖拽使用，保证了最佳实践的沉淀和统一。

设计一个健壮的Workflow，你需要考虑以下几点：

  • 节点输入/输出的强类型定义：每个节点明确声明它需要什么格式的数据（如一个字符串，或一个JSON对象），产出什么格式的数据。这能在编排阶段就发现很多数据对接的错误。
  • 状态持久化：Workflow的执行状态（执行到哪一步，中间产生了什么数据）必须能持久化到数据库。这样即使服务重启，也能从断点恢复，而不是从头再来。这对于处理长耗时任务（如生成一份报告）至关重要。
  • 异步与并发：不互相依赖的节点应该能并行执行，以缩短整体响应时间。Workflow引擎需要妥善管理任务队列和并发度。

实操心得：不要一开始就追求大而全的Workflow设计。从一个核心的、线性的流程开始，比如“用户提问 -> RAG检索 -> LLM生成回答”。先用代码实现，等这个流程稳定后，再将其模块化，并考虑引入Workflow编排工具进行可视化管理和增强稳定性。

2.2 RAG：给大模型装上“外部知识库”的导航系统

RAG（Retrieval-Augmented Generation，检索增强生成）无疑是当前让大模型落地专业领域最火的技术。它的原理很直观：当用户提问时，先从你的专属知识库（向量数据库）里找到最相关的文档片段，然后把“问题+相关片段”一起喂给大模型，让它基于这些片段生成答案。

但很多人做RAG，效果并不好，变成了“垃圾进，垃圾出”（Garbage In, Garbage Out）。问题出在“检索”这个环节。你以为的RAG：精准找到答案片段。实际上的RAG：找到了一堆似是而非的内容，导致LLM胡言乱语。

构建一个高效的RAG系统，关键在于治理好“检索”的质量。这包括以下几个层面：

  1. 文档预处理与分块（Chunking）：这是源头。直接把整本PDF扔进去切分成固定大小的块（比如512个token），是最糟糕的做法。正确的做法是根据文档结构进行智能分块，比如按章节、按段落，甚至按语义。确保每个“块”是一个相对完整的语义单元。同时，要处理好表格、代码等特殊格式，避免切分后失去意义。
  2. 向量化模型（Embedding Model）的选择与微调：通用的Embedding模型（如text-embedding-3-small）在通用领域不错，但在你的专业领域（如法律、医疗、金融）可能表现不佳。如果效果不满意，可以考虑用领域数据对开源Embedding模型（如BGE、M3E）进行微调，哪怕只有几千条高质量数据，效果提升也可能非常明显。
  3. 检索策略的优化：
    • 多路召回：不要只依赖向量检索。可以结合关键词检索（如BM25），因为有些专业术语的精确匹配很重要。将向量检索和关键词检索的结果融合，能提高召回率。
    • 重排序（Re-ranking）：初步检索可能返回10个相关片段，但其中只有3个是真正有用的。用一个更精细但更耗时的重排序模型（如Cohere的rerank，或微调一个MiniLM）对这10个结果重新打分排序，只取Top 3给LLM，能显著提升答案质量。
    • 查询转换（Query Transformation）：用户的原始提问可能很模糊。可以先让LLM对查询进行改写、扩展或生成假设性答案，再用改写后的查询去检索，效果更好。
  4. 上下文管理：检索到的片段，加上系统指令、用户问题，总长度不能超过LLM的上下文窗口。你需要一个策略来精选和压缩这些片段。比如，如果片段太多，可以用LLM自己来做一个摘要，或者只选择与问题最相关的句子。

一个进阶思路是Agentic RAG：不是一次检索就结束，而是让LLM扮演一个“研究员”，它可以根据初步检索的结果，自主提出新的、更深入的问题，进行多轮检索，迭代式地收集信息，最后综合给出答案。这更接近人类的思考过程，能处理更复杂的问题，但对系统设计和成本控制要求也更高。

2.3 记忆治理：让AI拥有“恰到好处”的记忆力

记忆是对话式AI（如聊天机器人、智能助手）的灵魂。没有记忆，每次对话都是全新的开始，用户体验极差。但记忆如果处理不好，问题更多：

  • 记忆混乱：把用户A说过的话，记到了用户B的头上。
  • 记忆膨胀：对话越长，塞进上下文的历史消息越多，不仅拖慢速度、增加成本，还可能因为上下文太长导致模型性能下降（“中间遗忘”现象）。
  • 隐私泄露：不小心把敏感的历史对话信息暴露给了后续无关的请求。

记忆治理，就是系统地设计和管理AI对历史信息的存储、提取和遗忘机制。它远不止是“把历史对话记录都存下来”那么简单。

一个完整的记忆系统通常包括：

  1. 短期记忆（会话记忆）：存放在当前对话的上下文窗口内。管理关键是摘要和压缩。当对话轮次变多时，可以用LLM自动将之前的对话历史总结成一段精炼的摘要，然后用这个摘要替代冗长的原始记录，作为新的“记忆”放入上下文。这样既保留了关键信息，又节省了空间。

  2. 长期记忆（外部记忆）：存储在向量数据库或关系型数据库中。这里的关键是结构化存储和索引。不能简单地把整段对话存进去。应该将记忆分类，比如：

    • 用户事实：“我的名字是张三”，“我在北京工作”。
    • 用户偏好：“我喜欢喝美式咖啡”，“报告格式要用PPT”。
    • 对话历史摘要：每次会话结束后生成的总结。
    • 知识片段：用户曾经分享过的、或系统检索到的有用知识。 存储时，要打好标签（用户ID、会话ID、记忆类型、时间戳）。检索时，根据当前对话的上下文，有针对性地去长期记忆中搜索相关记忆（例如，当用户说“跟上次一样”时，就去检索同类型任务的执行记录）。

  3. 记忆的激活与注入：不是所有长期记忆在每次对话时都塞给模型。需要一个“记忆检索”模块，根据当前用户query，去长期记忆中查找最相关的几条（比如3-5条），然后以自然语言的形式，作为系统提示词的一部分，“悄悄”注入给LLM。例如，在提示词开头加上：“以下是关于当前用户的已知信息：他叫张三，喜欢简洁的回答...”。

  4. 记忆的更新与遗忘：记忆不是一成不变的。当用户说“我换工作到上海了”，系统需要能更新“工作地点”这条记忆。同样，也需要设计遗忘策略，比如自动清理超过一定时间、或长期未激活的次要记忆，以保护隐私和控制存储成本。

踩坑实录：我曾做过一个客服助手，初期把所有历史QA都存进向量库。结果发现，当用户问“怎么退款”时，系统经常检索到几个月前另一个用户的复杂退款案例细节，导致当前回答变得冗长且不具普适性。后来我们改为只存储“通用解决方案”和“用户个人状态”，并严格按会话隔离记忆，问题才得以解决。

2.4 幂等性：分布式AI系统中的“安全阀”

幂等性是一个来自分布式系统的经典概念，意思是同一个操作，执行一次和执行多次，产生的最终效果是一样的。在AI应用里，这至关重要，因为网络可能超时、前端可能重复点击、任务可能失败重试。

想象这些场景：

  • 用户点击“生成周报”按钮，因为网络慢，他点了三次。结果生成了三份一模一样的周报，并创建了三个重复的待办任务。
  • 一个处理订单的AI Workflow，在调用支付接口后，更新数据库时失败了。Workflow引擎自动重试，导致同一笔订单被扣款两次。
  • 一个AI绘图应用，用户提交提示词后，后端处理超时，用户重新提交，导致队列里堆积了重复任务。

没有幂等性设计的AI应用，在线上就是一颗定时炸弹。

实现AI应用的幂等性，主要靠两个手段：

  1. 客户端生成唯一请求ID：前端或调用方在发起请求时，生成一个全局唯一的ID（如UUID），并附带在请求中。服务端在收到请求后，首先以这个ID为键，检查是否已经处理过。

    • 如果没处理过，就执行业务逻辑，并将处理结果与这个ID绑定后存入缓存（如Redis，设置合理的过期时间）。
    • 如果已经处理过，则直接从缓存中返回上一次的结果，不再执行后续的模型调用和业务操作。 这是最有效、最通用的方法。

  2. 服务端幂等令牌：服务端提供一个接口，让客户端先获取一个一次性的“令牌”。客户端带着这个令牌发起业务请求。服务端验证令牌是否有效且未被使用过，如果是，则执行业务并标记令牌已使用；后续携带相同令牌的请求将被直接拒绝。这种方式对客户端逻辑有一定要求。

在Workflow中实现幂等性需要更细致的考虑：因为一个Workflow包含多个步骤。我们的目标不仅是整个流程幂等，最好每个关键步骤（尤其是调用外部API或写数据库的步骤）也是幂等的。实现方式可以是：

  • 在Workflow的初始参数中传入唯一ID。
  • 每个节点在执行前，检查本次执行（由Workflow实例ID+节点ID+输入参数哈希共同确定）是否已完成。
  • 对于写操作，使用“唯一约束”或“乐观锁”来防止数据库层面的重复创建。

3. 实操构建：一个融合四大核心的智能问答系统

理论说再多，不如动手搭一个。我们设计一个简单的“智能技术问答助手”，它融合了Workflow、RAG、记忆和幂等性。

系统目标：用户可以通过自然语言提问技术问题（如“Spring Boot如何整合Redis？”）。系统能利用内部技术文档（RAG）和记住用户过往的提问偏好（记忆），通过一个可靠的工作流给出答案，并且即使用户重复提交相同问题，也不会重复消耗资源。

3.1 系统架构与组件选型

我们采用分层架构，清晰分离关注点：

[用户界面] -> [API网关] -> [业务逻辑层] -> [核心服务层] -> [数据存储层]
  • 用户界面：简单的Web页面或聊天窗口。
  • API网关：处理路由、认证、限流。在这里实现第一道幂等性检查（基于请求ID）。
  • 业务逻辑层：包含我们的核心Workflow编排器。我们选择Dify作为Workflow编排工具，因为它提供了可视化的界面，能很好地封装LLM调用、工具调用和条件逻辑。
  • 核心服务层：
    • RAG服务：负责文档处理、检索和重排序。我们用FastAPI快速搭建。
    • 记忆服务：管理用户的长短期记忆。同样用FastAPI。
    • LLM网关：统一对接不同的大模型API（如OpenAI、通义千问、DeepSeek），便于切换和降级。
  • 数据存储层：
    • 向量数据库：用于存储文档块和长期记忆中的知识片段。选用ChromaDB，轻量且易于集成。
    • 关系型数据库：用于存储用户信息、对话会话、结构化记忆（如用户偏好）、以及幂等性令牌。选用PostgreSQL。
    • 缓存：用于存储幂等性请求的结果和临时会话数据。选用Redis。

3.2 核心Workflow编排详解

我们在Dify中设计一个名为“技术问答”的Workflow，它包含以下节点：

  1. 输入节点：接收用户问题（query）和用户ID（user_id）。同时，要求前端必须传入一个request_id。
  2. 幂等性检查节点（自定义工具节点）：这是一个Python代码节点。它接收request_id，连接Redis，检查idempotent:${request_id}这个键是否存在。
    • 如果存在，直接从Redis中取出存储的answer和status，并跳转到最终输出节点，结束流程。
    • 如果不存在，继续执行后续节点，并在最终成功时，将结果写入Redis，设置过期时间（如5分钟）。
  3. 记忆检索节点（自定义API节点）：调用内部的“记忆服务”API，传入user_id和当前的query。记忆服务会从PostgreSQL和ChromaDB中检索与该用户相关的长期记忆（如“该用户偏好代码示例”、“上次询问过Docker相关问题”），并返回一段文本格式的记忆上下文（memory_context）。
  4. RAG检索节点（自定义API节点）：调用“RAG服务”API，传入query。RAG服务会从技术文档的ChromaDB向量库中检索最相关的3个文档片段，并进行重排序，返回检索到的内容（rag_context）。
  5. 提示词组装节点（变量处理节点）：将query、memory_context、rag_context以及系统指令组装成最终的提示词（final_prompt）。系统指令示例：“你是一个资深技术专家，请基于以下已知技术文档和用户历史偏好，专业且清晰地回答问题...”。
  6. LLM调用节点（Dify大模型节点）：配置连接我们的LLM网关，发送final_prompt，获取模型生成的答案（llm_answer）。
  7. 记忆更新节点（自定义API节点）：异步调用“记忆服务”的更新接口，将本次问答的核心内容（例如，将query和llm_answer的摘要）作为一条新的知识记忆，存储到该用户的长期记忆中。
  8. 输出节点：将llm_answer返回给用户，同时，在Workflow的上下文变量中标记本次执行成功。

这个Workflow通过Dify的可视化界面连接起来，并可以设置每个节点的错误处理策略（如重试、超时）。整个流程清晰、可监控，并且具备了幂等性保障。

3.3 RAG服务与记忆服务的实现要点

RAG服务实现关键点：

  • 文档分块：我们使用langchain的RecursiveCharacterTextSplitter，但设置较小的块大小（200字符）和较大的重叠（50字符），并尝试按Markdown标题进行分割，以保留更多上下文。
  • 检索融合：同时使用ChromaDB的向量检索和rank_bm25进行关键词检索，然后取并集，再用一个轻量级的重排序模型（如BAAI/bge-reranker-v2-m3）对合并结果进行精排。
  • API设计：提供一个/retrieve接口，接受query和top_k参数，返回一个结构化的JSON，包含文档片段列表和来源。

记忆服务实现关键点：

  • 记忆存储：在PostgreSQL中设计user_memories表，字段包括：id,user_id,memory_type(enum: ‘fact‘, ‘preference‘, ‘summary‘),content(text),embedding(vector, 用于语义检索),created_at,last_accessed_at。
  • 记忆检索：当收到检索请求时，首先用user_id和memory_type在数据库中进行筛选，然后对筛选出的content用向量进行相似度搜索（使用pgvector扩展），返回最相关的几条。
  • 记忆摘要与压缩：每次对话结束后，可以触发一个异步任务，用LLM将本次对话总结成一段话，存入memory_type=‘summary‘的记忆中。在检索时，近期摘要的权重可以更高。

4. 常见问题、排查技巧与优化方向

即使设计得再完善，实际运行中也会遇到各种问题。下面是一些典型问题及我的排查心得。

4.1 Workflow执行卡住或失败

  • 问题现象：Workflow在某个节点长时间运行，或直接报错失败。
  • 排查思路：
    1. 查看节点日志：这是第一步。Dify等工具会记录每个节点的输入输出。检查失败节点的输入数据是否符合预期。常见问题：上游节点传过来的数据格式不对，比如期望是字符串，却收到了一个对象。
    2. 检查外部依赖：如果节点调用了外部API或数据库，检查网络是否通畅、API密钥是否有效、数据库连接是否正常。务必为所有外部调用设置合理的超时时间和重试策略。
    3. 检查资源限制：如果使用云服务，检查是否触发了速率限制（Rate Limit）。例如，LLM API的调用频率、向量数据库的连接数。
    4. 简化流程，分步调试：在复杂Workflow中，可以暂时注释掉后续节点，只运行到出问题的节点，逐步定位。

4.2 RAG效果不佳，答案不准确或胡编乱造

  • 问题现象：LLM的回答没有基于提供的文档片段，或者检索到的片段完全不相关。
  • 排查技巧：
    1. 检查检索输入：打印出发送给向量数据库的查询文本。有时需要对用户原始查询进行清洗或扩展（例如，补全为完整的句子）。
    2. 评估向量质量：随机采样一些文档块，计算它们之间的相似度。如果同一主题的块之间相似度很低，说明Embedding模型可能不适合你的领域，考虑微调。
    3. 检查检索结果：在返回给LLM之前，先把检索到的Top K个片段内容打印出来，人工判断它们是否与问题相关。如果不相关，问题出在检索环节；如果相关但LLM没用上，问题可能出在提示词或LLM本身。
    4. 引入“引用”机制：强制要求LLM在回答时，必须引用检索片段的编号（如[1], [2]）。这样你可以直观地看到它到底参考了哪些材料，便于调试。

4.3 记忆系统导致回答混乱或性能下降

  • 问题现象：AI的回答似乎受到了无关历史信息的干扰，或者随着对话轮次增加，响应速度变慢。
  • 解决方案：
    1. 实施严格的记忆过滤：在记忆检索时，不仅要看语义相关性，还要加入时间衰减因子和类型权重。例如，3天前的“偏好”记忆权重，可能高于3个月的“事实”记忆。
    2. 控制注入记忆的长度：设定一个硬性上限，比如所有注入的记忆文本总长度不超过500个token。超过则进行摘要压缩或丢弃权重最低的记忆。
    3. 定期清理：建立一个后台任务，定期清理last_accessed_at时间过久（如30天前）的长期记忆。

4.4 幂等性机制被绕过或失效

  • 问题现象：重复请求仍然导致了重复操作。
  • 常见陷阱与排查：
    1. 请求ID不唯一：确保前端生成的请求ID（如UUID）具有足够的全局唯一性。避免使用时间戳或简单递增数字，在并发下可能重复。
    2. 检查点设置不当：幂等性检查必须在任何有副作用的操作（如调用LLM、写数据库）之前进行。如果先操作，再写Redis，那么在操作成功后、写Redis前服务崩溃，重试时就会绕过检查。
    3. Redis键过期或丢失：确保为幂等性键设置合理的过期时间（根据业务逻辑，如5分钟到1小时）。同时考虑Redis持久化问题，在极端情况下，如果Redis数据丢失，需要有降级方案（例如记录日志，人工核对）。
    4. 分布式环境下的竞争条件：在高并发下，两个相同的请求可能同时通过“检查键不存在”的判断。为了解决这个问题，可以使用Redis的SETNX（SET if Not eXists）命令，它是一个原子操作，可以安全地实现分布式锁或幂等性标记的创建。

构建一个健壮、可靠的AI应用，技术选型和模型效果只是冰山一角。水面之下，是Workflow、RAG、记忆治理、幂等性这些工程化基石在提供支撑。它们决定了应用是否能平稳运行、是否能理解用户、是否能安全可靠。我的经验是，在项目启动的初期，就至少要为这些核心概念留出设计时间，哪怕先实现一个最简单的版本。比如，先实现基于请求ID的幂等性，先搭建一个基础的、可监控的线性Workflow，先做一个简单的向量检索。随着业务复杂度的增长，再逐步迭代优化。忽略这些，等到线上事故频发、用户投诉不断时再回头补课，代价要大得多。AI应用的开发，正从“模型调优”的蛮荒时代，走向“系统工程”的精耕时代。

编程学习 学习日记 实战经验
← 返回列表