虽然向量 (vector)数据库在从非结构化文本中检索语义相似信息方面表现出色，但当智能体需要访问确切事实、复杂关联或由明确模式管理的数据时，它们往往力有不逮。获取 product_sku_12345 的确切当前库存量，或绘制模拟组织内的层级汇报结构，都需要能理解并处理显式结构的机制。正是在这里，结构化记忆表示，例如知识图谱和关系数据库，成为智能体记忆架构中的重要组成部分。它们通过提供对精心整理、相互关联且可验证信息的访问，对非结构化检索形成补充。
知识图谱（KG）作为记忆
知识图谱将信息表示为实体（节点）和关系（边）的网络。实体可以是任何人、地点或抽象观念，而边则定义了这些实体如何关联（例如，位于、管理、一部分）。这种结构本身适合存储复杂的关联知识、分类法和本体论信息，智能体可以查询以获取特定信息。
与大型语言模型（LLM）智能体的集成：
智能体通常通过专用工具或界面与知识图谱进行交互。这种交互通常包括：
- 查询形成： 智能体根据其推理 (inference)过程，确定需要特定结构化信息。它可能会使用标准知识图谱查询语言（如SPARQL用于RDF图，或Cypher用于属性图）形成查询，通常是通过提示LLM将自然语言问题翻译成形式化查询。
Cypher查询生成示例：
自然语言： “‘数据科学团队’目前被分配到哪些项目？”
生成的Cypher查询：
MATCH (t:Team {name: 'Data Science Team'})-[:ASSIGNED_TO]->(p:Project) RETURN p.name
- 查询执行： 形成的查询将针对知识图谱数据库（例如Neo4j、Amazon Neptune、RDF4J）执行。
- 结果解析： 返回的结果（通常是JSON等结构化格式）被解析并整合回智能体的操作语境或短期记忆中。这可能涉及总结发现或提取智能体计划下一步所需的特定数据点。
- 知识图谱更新（高级）： 在某些情景下，智能体可能被授予更新知识图谱的权限，根据它们处理的信息添加新的实体或关系。这需要谨慎实施，并带有验证步骤以维护数据完整性。
知识图谱的一个简单片段，描述了项目管理关系，可能存储在一个智能体可访问的图数据库中。
知识图谱为智能体访问复杂、相互关联的事实提供了一种有效方式，而这些事实仅靠嵌入 (embedding)难以表示或可靠检索。
关系数据库（SQL DB）作为记忆
传统关系数据库仍是存储大量结构化表格数据的重要支撑。对于智能体系统，SQL数据库可以作为记忆来源用于：
- 事务记录： 销售数据、事件日志、交互历史记录。
- 实体属性： 用户档案、产品目录、配置设置。
- 操作状态： 当前库存量、系统状态标志、工作流进度。
与LLM智能体的集成：
交互通常遵循文本到SQL模式：
- 模式感知： 智能体需要访问数据库模式（表名、列名、类型、关系）以形成有效查询。这种模式信息可以在智能体的提示中提供，通过专用工具获取，或嵌入 (embedding)到LLM的微调 (fine-tuning)数据中。
- SQL查询生成： LLM将智能体的数据自然语言请求翻译成SQL查询。这是一项复杂任务，易于出错，例如语法错误、虚构的表名/列名或低效的查询结构。谨慎的实现需要细致的提示工程 (prompt engineering)、少样本示例，以及可能经过微调且专门用于文本到SQL的模型。
文本到SQL示例：
自然语言： “显示过去30天内订购了产品‘X’的加利福尼亚客户的电子邮件地址。”
生成的SQL查询：
SELECT T1.email
FROM customers T1
JOIN orders T2 ON T1.customer_id = T2.customer_id
JOIN order_items T3 ON T2.order_id = T3.order_id
WHERE T1.state = 'CA'
AND T3.product_name = 'X'
AND T2.order_date >= date('now', '-30 days');
- 查询执行与安全： 直接在生产数据库上执行LLM生成的SQL会带来重要的安全风险（SQL注入）和潜在的意外数据修改（更新/删除）。执行应在沙盒环境中进行，在可能的情况下使用只读连接，采用查询净化，并可能包含人工参与的验证步骤以处理敏感操作。
- 结果处理： 查询结果（通常是表格形式）返回给智能体，需要解析并整合到其工作记忆中。
混合结构化和非结构化记忆
通常，最有效的记忆架构结合了结构化和非结构化方法。智能体可能使用向量 (vector)数据库来查找讨论通用主题（例如“关于产品X的客户反馈”）的相关文档，然后查询SQL数据库以获取与该反馈中提到的实体相关的精确结构化数据（例如“获取反馈文档ID 987中提到的客户ID 5678的订单历史”）。
混合检索方法包括：
- 实体链接： 识别非结构化文本中的实体（人员、组织、产品），并用它们查询知识图谱或SQL数据库以获取详细属性或关系。
- 知识图谱增强检索： 借助知识图谱中的关系或元数据来优化或扩展发送到向量数据库的查询。例如，不仅查找与“阿尔法项目”相关的文档，还查找与知识图谱中该项目关联的团队成员相关的文档。
- 结构化数据丰富： 检索结构化数据（例如从SQL获取产品规格），并将其与非结构化描述一起嵌入 (embedding)向量存储，以便在语义搜索中提供更丰富的语境。
实施考量
集成结构化记忆需要细致的设计：
- 工具定义： 将知识图谱/SQL查询能力表示为具有清晰描述、输入/输出模式，并可能为LLM规划器提供示例的工具。
- 查询验证： 实施检查，确保生成的查询（SPARQL、Cypher、SQL）在执行前语法正确且语义合理。这可能涉及解析器、linter，甚至使用LLM本身进行验证提示。
- 模式管理： 制定策略为智能体提供最新的模式信息，而不占用过多上下文 (context)窗口空间。这可以包括模式总结或按需检索。
- 安全与权限： 建立严格的访问控制、读/写权限和查询过滤，以防止未经授权的访问或有害操作，尤其当智能体可以触发更新或删除时。
通过结合知识图谱和关系数据库，我们使LLM智能体能够访问并推理 (inference)精确、事实性且相互关联的信息。这补充了基于向量 (vector)检索的优点，使智能体能够应对更广泛的复杂任务，既需要语义理解又需要结构化数据访问。知识图谱与SQL数据库之间的选择，或决定两者都用，在很大程度上取决于数据的具体性质和智能体设计要执行的任务。
