构建双层级长期记忆系统：解决Text-to-SQL Agent的“健忘症”难题

1. 项目缘起：当Text-to-SQL遇上“记忆”难题

最近在折腾一个智能数据分析助手项目，核心功能是让用户用自然语言提问，比如“帮我查一下上个月销售额最高的三个产品”，系统能自动生成对应的SQL语句去数据库里跑出结果。这听起来就是典型的Text-to-SQL任务，对吧？市面上基于大语言模型（LLM）的解决方案已经很多了，从简单的提示工程到复杂的工具调用框架，似乎都能做。

但在真实业务场景里跑上一阵，一个根本性的痛点就暴露出来了：“健忘症”。今天你问助手“什么是活跃用户？”，我精心设计提示词，告诉它我们业务里“活跃用户”的定义是“过去30天内有登录且完成至少一次下单的用户”。它学得挺好，生成的SQL完美无缺。可过了两天，另一个同事又问“查一下活跃用户数”，它可能就给你一个完全不同的、甚至是错误的定义。更头疼的是复杂的业务逻辑，比如一个涉及多表关联、多层子查询的“用户生命周期价值”计算，每次都要在提示词里把长达十几行的逻辑描述重新塞给模型，不仅浪费宝贵的上下文窗口，响应速度慢，成本也高得吓人。

这本质上是一个长期记忆（Long-Term Memory）缺失的问题。现有的Agent，无论是ReAct、AutoGPT还是LangChain的各种变体，其“记忆”大多局限于单次会话的上下文（短期记忆），或者需要依赖昂贵的向量数据库进行相似度检索，而后者在应对精确、复杂的业务逻辑匹配时，常常力不从心，检索出来的可能只是“形似而神不似”的片段，无法保证逻辑的准确复现。

直到我看到了“Learning to Retrieve: Dual-Level Long-Term Memory for Text-to-SQL Agents”这个研究方向，它直指问题的核心。它不再把记忆当作一个静态的、被检索的仓库，而是提出了一个更聪明的思路：让Agent学会主动学习如何检索。所谓的“Dual-Level”（双层级），我的理解是它构建了两套记忆与检索机制：一层负责记住那些通用的、模式化的“技能”（比如如何连接特定的表，如何解析时间范围），另一层则负责记忆具体的、历史成功的“案例”（比如那个精确的“活跃用户”查询逻辑）。当新问题到来时，Agent不是盲目地搜索，而是先判断这个问题更依赖于哪种记忆，然后调用对应的“检索器”去获取最相关的知识，最后再综合生成SQL。

这就像一位经验丰富的DBA（数据库管理员），他脑子里既有通用的SQL编写规范（第一层记忆），也有过去处理过的无数个疑难工单的解决方案（第二层记忆）。面对一个新需求，他会先快速归类，然后从对应的“知识抽屉”里提取经验，而不是每次都从头开始思考。接下来，我就结合自己的实践和这个方向的研究，拆解一下如何为你的Text-to-SQL Agent构建这样一个“双层级长期记忆”系统。

2. 拆解“双层级记忆”：技能库与案例库的协同

要构建有效的记忆，首先得明确我们要记什么。在Text-to-SQL场景下，信息并非铁板一块，我们可以将其大致分为两类，这也对应了双层级记忆的设计。

2.1 第一层：模式化技能记忆（Skill Memory）

这一层记忆的目标是捕获那些可复用、相对稳定的查询模式与领域知识。它不那么具体，更像是一套“语法”或“套路”。

• 数据库模式（Schema）知识：这是基础中的基础。但不仅仅是表名和列名，更重要的是它们之间的关系（外键）、数据类型、以及某些字段的业务含义注释。例如，orders.status字段，值‘P’、‘S’、‘C’分别代表“待支付”、“已发货”、“已完成”，这个映射关系就应该被牢牢记住。
• 通用查询模板：某些查询模式反复出现。例如，“统计某时间段内的【指标】，按【维度】分组，并排序”。这可以抽象成一个带有占位符的模板。再比如，如何处理“最近7天”、“上个月”这种相对时间表述，可以抽象成一套固定的时间转换规则。
• 常见函数与操作：业务中频繁使用的聚合函数（SUM,COUNT(DISTINCT ...)）、日期函数（DATE_TRUNC,INTERVAL）、字符串处理函数等。记忆它们的使用场景和典型参数。
• 领域特定约束与规则：例如，“销售额”永远取order_items.quantity * products.price，并且只计算状态为‘C’（已完成）的订单。这是一条硬性的业务规则。

这一层记忆的存储与检索关键在“结构化”和“索引化”。我们可以将数据库Schema信息（表、列、类型、关系、注释）结构化存储。查询模板和业务规则可以用一种自定义的DSL（领域特定语言）或JSON格式来描述。检索时，不是做模糊的语义匹配，而是进行精确的关键词匹配或规则匹配。例如，用户问题中出现“销售额”，我们直接触发“销售额计算规则”；出现“按城市分组”，我们就关联到“分组统计模板”。

2.2 第二层：具体化案例记忆（Case Memory）

这一层记忆则是“血肉”，存储的是历史成功交互的具体实例。每一个案例都是一个三元组：<自然语言问题， 生成的SQL， 执行结果（或验证状态）>。

• 问题-SQL对：这是最直接的学习材料。一个高质量的案例，其自然语言问题应该清晰，生成的SQL准确且高效。
• 执行上下文：光有SQL可能还不够。记录下生成该SQL时的上下文信息也很有价值，比如当时的数据库快照信息（某些临时表的存在）、用户对话的历史（可能这个问题是上一个问题的延续）。这有助于理解SQL的完整意图。
• 反馈与修正：如果一个SQL第一次执行出错，经过人工或自动修正后成功了，那么错误的SQL、错误信息、修正后的SQL这个完整链条是极其宝贵的记忆。它直接教会Agent“何种问题会导致何种错误，以及如何纠正”。

这一层记忆的检索核心在于“相似度”。当新问题到来时，我们需要从案例库中找到最相似的历史问题。这里就不能只用关键词了，需要语义层面的相似度计算。传统的向量检索（如用Sentence-BERT生成嵌入，再用余弦相似度查找）是基础方法。但更重要的是，对于Text-to-SQL，问题之间的相似性应该体现在其“查询意图”的相似性上，而不仅仅是表面文字的相似。例如，“展示销量前十的产品”和“哪些产品卖得最好”是高度相似的，尽管字面不同。

2.3 双层级如何协同工作：“学会检索”是关键

“Dual-Level”的精髓不在于简单的两个存储桶，而在于一个决策与路由机制——也就是标题中的“Learning to Retrieve”。我的实现思路是这样的：

1. 意图解析与路由：当新的用户查询到来时，先用一个轻量级的分类器或一组规则进行初步分析。这个分析器需要判断：

   • 这个问题是否强烈依赖于某个已知的业务规则或固定模式？（例如，直接问“销售额怎么算的？”或“我们的活跃用户标准是什么？”）如果是，则优先路由到技能记忆（第一层）进行精确检索。
   • 这个问题是否是一个相对自由的、综合性的查询？（例如，“帮我分析一下上周新用户的购买行为特征”）如果是，则路由到案例记忆（第二层）进行相似度检索，寻找最接近的历史案例作为参考。
   • 很多时候，一个问题是混合型的。例如，“按城市统计一下活跃用户的销售额”。这里既涉及“活跃用户”（技能记忆中的规则），又涉及“按城市统计销售额”（一个通用模板，也可能有类似案例）。这时就需要一个混合检索策略。

2. 检索器增强：对于第二层（案例）的检索，不能只依赖通用的文本嵌入模型。我们需要训练或微调一个专用于Text-to-SQL问题相似度判断的检索模型。这个模型的学习目标就是：判断两个自然语言问题，是否对应着语义相同或相似的SQL查询意图。我们可以利用历史案例库中的<问题1， SQL1>和<问题2， SQL2>数据，如果SQL1和SQL2在逻辑上等价（可以通过执行结果对比或抽象语法树AST对比来判断），那么即使问题1和问题2文字不同，它们也应该被判定为高度相似。用这样的数据对去训练检索模型的嵌入空间，能让它更懂“业务意图”。

3. 记忆融合与提示构建：从两层记忆中检索到相关内容后，如何有效地喂给LLM？直接拼接可能混乱。我采用的是一种结构化提示模板：

   你是一个资深数据分析师，请根据以下知识生成SQL。 【数据库Schema信息】 （从技能记忆中获取的相关表结构） 【重要业务规则】 （从技能记忆中触发的相关规则，例如：活跃用户定义为：...；销售额计算方式为：...） 【参考类似历史案例】 （从案例记忆中检索到的1-3个最相似案例，展示其“用户问题”和“成功SQL”） 【当前用户问题】 {current_user_query} 请综合以上信息，生成准确、高效的SQL语句。

   这种结构清晰地告诉了LLM不同信息的来源和优先级，显著提升了生成SQL的准确率和对业务规则的遵循程度。

3. 系统实现蓝图：从存储到检索的工程细节

理论说清楚了，我们来聊聊怎么落地。一个完整的双层级记忆系统，包含以下几个核心模块。

3.1 记忆存储层设计

• 技能记忆存储：我推荐使用一个关系型数据库（如PostgreSQL）或一个文档数据库（如MongoDB）来存储。

  • Schema信息：可以定期从生产数据库导出，存为一张表或一个集合，包含table_name,column_name,data_type,description,foreign_keys等字段。
  • 业务规则与模板：设计一个灵活的JSON Schema来存储。例如：

    { "rule_id": "RULE_SALES_CALCULATION", "type": "calculation_rule", "trigger_keywords": ["销售额", "sales", "营收"], "description": "计算商品销售额的总和", "sql_pattern": "SUM(order_items.quantity * products.price)", "condition": "orders.status = 'C'", "tables_involved": ["orders", "order_items", "products"] }

  • 通用模板：同样用JSON存储，描述模板结构、占位符和填充逻辑。

• 案例记忆存储：这里需要支持高效的向量相似度搜索，因此向量数据库是首选，如Pinecone、Weaviate、Qdrant，或者Milvus、Chroma等开源方案。

  • 每条案例作为一个向量记录存储。
  • 核心字段：case_id,natural_language_query（原始问题），generated_sql，query_embedding（由专用检索模型生成的问题向量），execution_success（布尔值），feedback（人工修正或注释），timestamp。
  • 在存储时，natural_language_query被送入我们微调过的检索模型，生成高维向量，然后存入向量数据库的索引中。

3.2 检索模型训练：让Agent“学会”找相似案例

这是实现“Learning to Retrieve”的技术核心。我们目标是得到一个模型，它能将查询意图相似的自然语言问题映射到向量空间中相近的点。

1. 数据准备：从历史日志或标注数据中，收集大量的<问题， SQL>对。然后，我们需要构建一个正样本对数据集。判断两个问题是否为“正样本”（即意图相似）的准则可以是：

   • SQL等价性：自动执行两个SQL，在相同的数据快照下，如果返回结果一致（或经过排序等规范化后一致），则认为它们意图相似。这是最可靠的信号。
   • 人工标注：对于无法自动判断的，进行小规模人工标注。
   • 问题重构：对同一个问题，用同义词改写、句式变换生成多个版本，它们天然是正样本。

2. 模型选择与训练：

   • 基础模型：选择一个强大的文本编码模型作为基础，如BGE、E5或Sentence-BERT系列。
   • 训练方法：采用对比学习（Contrastive Learning）。常用的损失函数是InfoNCE Loss。简单来说，在一个Batch里，对于每一个“锚点”问题，拉近它与正样本问题（意图相似）在向量空间的距离，同时推远它与负样本问题（随机选取的其他不相关问题）的距离。
   • 训练技巧：可以尝试难负样本挖掘（Hard Negative Mining），比如找那些SQL不同但表面文字相似的问题作为负样本，让模型学会区分更细微的差异。

3. 部署与推理：训练好的模型作为一个独立的微服务部署。当需要检索案例时，将当前用户问题输入该模型，得到其向量表示，然后用这个向量去向量数据库进行近似最近邻（ANN）搜索。

3.3 智能路由与记忆融合模块

这个模块是系统的大脑，负责协调两层记忆。

1. 路由判断器：可以是一个简单的基于关键词或规则的分类器，也可以是一个小型的文本分类模型（如训练一个BERT分类模型，判断问题类型）。输入是用户问题，输出是一个路由标签（如主要依赖技能记忆、主要依赖案例记忆、混合型）以及触发的技能关键词。
2. 混合检索流程：
   • 根据路由标签，并行或串行触发检索。
   • 技能记忆检索：根据触发的关键词，在业务规则库和模板库中进行精确查询或模糊匹配，返回相关的规则和模板片段。
   • 案例记忆检索：将用户问题送入专用的检索模型得到向量，在向量数据库中进行搜索，返回Top-K个最相似的案例。
   • 结果融合：将两部分检索结果按照预设的结构化提示模板进行组装，形成最终的上下文（Prompt），发送给LLM（如GPT-4、Claude或开源的CodeLlama-SQL等）进行SQL生成。

4. 实战中的挑战与优化策略

在实际构建和运行这套系统的过程中，我遇到了不少坑，也总结出一些优化点。

4.1 冷启动问题：记忆库空空如也怎么办？

系统刚上线时，案例记忆库是空的，技能记忆库也可能不完善。

• 策略一：种子数据注入。手动整理一批高频、经典的业务问题及其SQL，作为初始案例库。同时，将数据字典和已知的业务规则文档化，导入技能记忆库。这相当于给Agent做了“上岗培训”。
• 策略二：主动学习与人工审核闭环。在初期，将所有生成的SQL及其结果（或错误）都记录下来，但并不直接加入记忆库。设置一个审核队列，由数据分析师或DBA定期审核。将审核通过的、高质量的<问题， SQL>对，作为正样本加入案例库；将发现的业务规则，提炼后加入技能库。这个闭环是系统知识增长的引擎。
• 策略三：回译增强。对于已有的种子案例，可以运用LLM本身，对自然语言问题进行同义改写、扩展或生成不同表述，以此扩充案例的多样性，丰富检索模型的训练数据。

4.2 记忆冲突与过时：哪个记忆说了算？

当技能记忆中的规则和某个历史案例的SQL不一致时，听谁的？业务规则可能会变更。

• 版本化与时效性：为技能记忆中的业务规则引入版本号和生效时间。在检索时，优先应用最新版本的规则。对于案例记忆，每条案例可以有一个“置信度”或“权重”字段，来源于其执行成功率、人工审核标记等。在融合时，如果技能规则已更新，应以规则为准，并可以考虑对相关的旧案例打上“已过时”的标签，降低其检索权重或归档。
• 冲突检测与解决：可以设计一个简单的冲突检测流程。在生成SQL后，用一个规则引擎快速检查其是否违反了当前技能库中的任何核心约束。如果违反，可以触发一个警告或要求人工确认。

4.3 检索效率与成本平衡

向量检索虽然强大，但相比关键词检索，其计算开销更大。

• 分层检索：先使用快速的关键词匹配在技能记忆和案例的元数据（如问题中的核心实体词）中进行初筛，缩小候选集范围，再对缩小后的候选集进行精确的向量相似度计算。
• 缓存机制：对于高频或完全相同的用户问题，可以直接缓存其最终生成的SQL和记忆检索结果，下次直接返回，绕过LLM和复杂的检索流程。
• 记忆摘要：对于非常复杂的案例，存储完整的SQL和上下文可能占用大量空间。可以考虑存储一个“摘要”或“特征向量”，在检索时先匹配摘要，命中后再去加载完整细节。

4.4 评估与迭代：如何知道系统变聪明了？

不能盲目添加记忆，需要有评估指标。

• 离线评估：构建一个测试集，包含一系列有代表性的用户问题及其标注好的标准SQL。定期（如每周）在测试集上运行你的Agent，计算执行准确率（生成的SQL与标准SQL执行结果一致的比例）和语法正确率。观察随着记忆库的扩充，这些指标是否提升。
• 在线评估：在真实使用中，收集反馈。可以设计一个“拇指向上/向下”的反馈按钮。将用户标记为“失败”的案例，自动进入审核队列，用于分析和改进记忆库或检索模型。
• 检索质量评估：对于案例检索部分，可以评估检索到的案例与当前问题的真实相关性（可通过人工抽样或后续SQL生成的成功率间接判断）。

构建这样一个具有双层级长期记忆的Text-to-SQL Agent，确实比做一个简单的提示词包装要复杂得多。它涉及到数据工程、模型训练、系统架构等多个方面。但它的回报是巨大的：一个真正能积累经验、越用越聪明、能稳定遵循业务规则的智能助手，能极大解放数据分析师的生产力，让业务人员获取数据洞察的门槛降到最低。这个过程本身，也是一个让AI系统从“单次任务执行者”向“持续学习伙伴”演进的有益尝试。