记忆

记忆agent

需求

  1. 个人工具
    1.  作为第二大脑，思维助手，能帮助思考、总结
      1. 提升所有人的智力水平
      2. 带无限的记忆，超越人类
      3. 通过Agent（人工算法+LLM）的方式实现高层级抽象、意识、复杂逻辑。Agent的不断运行类似于人脑的逐步思考
    2. 信息工具，不仅仅是笔记
      1. 实现一些基本的对信息的思维逻辑操作
      2. 优秀的人工接口，自然，聪明
  2. 独立系统
    1.  不断学习知识，通过庞大的记忆和渐进式推理能力，攻克领域问题
    2. 作为一个独立的生产力工具
  3. 资料库
    1. 存储所有可能的信息作为数据库
    2. 分等级的信息存储和索引
      1. 自己写的笔记
      2. 阅读过的文章
        1. 添加简易评论和信息，用于AI自动检索和处理关系
        2. 大脑只能记住比较抽象和高级别的印象，AI根据这个印象联系到详细的信息
      3. 没有阅读的相关的各种论文，网络文章
      4. 书籍
    3. 对资料库进行分析和抽象，建立知识树，知识逻辑关系，快速像大脑一样在大量的知识里面整理信息
      1. 这一设计模拟了人类解决复杂问题时的策略：边查边记、反复比对、直至知识充分
  4. 本地数据库管理知识的片段，在密集的信息堆里面不断的编织，把LLM当作是信息的运算器
    1. 多次检索：是否支持多次检索。
    2. 自适应检索：是否能根据当前信息动态地决定是否需要执行进一步的检索动作以及检索什么。
    3. 模型训练：是否对不同阶段进行了针对性训练或偏好优化。
    4. 一次性知识总结：是否在检索后执行一次性检索知识总结。
    5. 迭代知识总结：是否支持在多轮检索中多次更新、积累、总结知识。
  5. 需要支持一些特殊的信息形式的模版: Jira, wiki, todo_list

AI笔记可能的级别

  1. 骨灰
    1. 主动执行一些复杂的任务
      1. 从笔记里面的链接提取出特定的信息
      2. 主动搜索互联网的相关信息，进行知识补充和整理
  2. 专家
    1. 纯自然语言的交互方式，表达和输出
    2. 所有的信息都由AI对输入进行格式化后记录，采用符合要求的自然语言的表达方式进行输出
    3. 对记录的所有信息进行整理，归类，合并，推理后更新记录
    4. 工具自动对信息进行逻辑判断，生成需要的总结和新结论
    5. 不输出原始笔记
  3. 高级工具
    1. 定义一套通用的笔记表达接口
    2. 按照固定的模版或者规范进行对笔记表示、整理、记录，形成固定的格式化的笔记条目
      1. 比如层级式的笔记方法，好理解，表达力强，正如本文
    3. 通用的信息表达方案
  4. 工具
    1. 存储原始的笔记信息文本
    2. 支持自然语义搜索原文

应用界面和交互

  1. 不能仅仅通过对话的形式，应该支持更复杂的交互方式
    1. 自动提供可能的操作选项
    2. 框选字段作为输入
  2. 不仅仅是笔记输入
    1. 屏幕框选和注释
    2. 文章、链接、引用
    3. 输入是思维片段、文本片段，录音，视频，文档，摘要，想法，手稿
  3. 类似于: 代码生成工具，主动提示等
  4. 通过问答的形式交互
  5. 个人思维助理，管家
    1. 输入日历、行程
    2. 导入短信、聊天记录
    3. 接入网盘、照片、云盘

实现1

  1. 数据库记录信息之间的关系
  2. LLM模型通过多步操作API进行交互式的信息生成和编辑
  3. 存储原始的输入的文本、信息
  4. 支持对输入的信息，文本进行结构化，由标签和固定的格式进行表示
    1. 使用固定的逻辑表达式进行编码？
  5. 通过标签和逻辑表达式，查询需要的信息
  6. 对一个或者多个表达式进行转换和处理生成一个表达式

  7. LLM的操作

    1. 根据一段信息生成对应的标签和对应的相似度，可以指定提取信息标签的深度、精细度
    2. 计算一个标签和其他标签的关系，充分，必要，充要，不充分，不必要
    3. 标签的逻辑关系表的存储和查询修改接口
    4. 一个自然语言的问题，输出以标签作为输出的结果，“标签的逻辑关系表”的增删查改的操作
    5. 支持多次交互的LLM操作
      1. 反向Prompt引导深度思考，反逻辑
      2. 多版本对比与迭代
      3. 多个LLM相互验证，能进行自我验证和测试正确性
      4. 结构化输出控制

实现2

  1. 基于LLM的专用meaning处理大模型：小规模，缓慢更新迭代
    1. 功能 
      1. 处理固定的已知的有限的逻辑，生成meaning，形成meaning tree
        1. 逻辑关系类
        2. 已知的名词、事物
      2. 支持生成和识别已知的meaning的组合
      3. 输出和输出特殊的高效的meaning token：meaning tree
      4. 使用AI算法，对meaning tree 进行处理、总结
        1. 分析形成高级抽象meaning，存储与数据库
          1. 通过低层级的通用语义（单词）的逻辑组合，不断组合成高层级语义
          2. 形成由逻辑关系不断组合形成的“逻辑树”，存储与数据库
          3. 可以先总结底层（短语）级别，逐渐形成更高级的逻辑树
        2. 数据库+传统算法+AI处理数据
          1. 由LLM生成待查询的逻辑需求
          2. 数据库按照固定的逻辑进行查询输出
          3. LLM不断一步步进行“查询”“处理”直到不需要查询更多信息
    2. 实现？
      1. 使用更大的LLM进行训练数据生成：文本->meaning token的数据集
  2. 结合meaning tree+原文，推理meaning， 生成prompt
  3. 数据库记录meaning和原文，以及之间的关系：不断更新数据
  4. 公用的LLM根据prompt组织生成自然语言：通用的大规模LLM

接口

  1. 数据定义

    1. 信息：一段通用的文本信息：包含level的信息
    2. 标签：简短的一种信息，level较高，可以使用逻辑关系组合成标签树
    3. 关系：包含所有可能的信息之间的关系

  2. LLM接口

    1. 使用指定的标签列表对一段信息进行格式化

      1. 对信息进行格式化，解释
      2. 输出使用标签和逻辑关系组成的标签树

    2. 输入一大堆信息/标签，根据指定的标签树，提取和摘录对应的结果

      1. 根据标签进行查询、匹配

    3. 输入两个（多个）信息/标签树，判断合理性，有无矛盾

  3. 数据库接口

    1. 查询输出指定level的标签
    2. 根据标签树输出所有相关信息
    3. 增加信息、标签、关系
    4. 删除指定的信息、标签、关系

可能的方案

  1. RAG
  2. graphrag  nano-graphrag
  3. Google NotebookLM
  4. 开源onyx https://github.com/onyx-dot-app/onyx
  5. kivy作为本地跨平台APP开发，python， 底层SDL2 性能好，多平台
  6. https://github.com/reflex-dev/reflex 开发web程序 纯python
  7. svelte web开发框架 + pocketBase数据库
  8. 使用gradio https://github.com/gradio-app/gradio.git 纯python，svelte底层，集成度高
  9. MemOS  Memory3项目

  10. A-MEM: Agentic Memory for LLM Agents

记忆

为什么需要记忆

  1. 人脑有非常强大的记忆系统和索引能力，管理着非常庞大的信息，能够准确联想起来非常多的记忆
    1. 记忆是AGI的一种重要能力
  2. 因为大脑容量限制，记忆是人类在当前信息爆炸的社会的最重要瓶颈
    1. 其他的还有类似：推理逻辑能力，运算能力等等
    2. 刨除记忆能力，其他的能力当前LLM已经有一个比较可用的实现
    3. 记忆能力可能成为下一个快速增长的瓶颈点
      1. 是不是未来会是：一个专注于基本语言和推理能力的小模型+大型的记忆系统
      2. 不断的提升记忆内容的质量（效率，自洽度...）、内容的数量、效率
  3. 数据库样式的存储记忆（类似RAG）不能满足现代需求
    1. 没有进行良好的抽象、归纳和整理，只是靠搜索引擎进行匹配检索
      1. 不能根据已经有的背景知识进行复杂的逻辑推导
      2. 不能利用知识进行慢思维（系统二）
    2. 不能用于复杂的深度推理思考活动
      1. 当前AI能利用搜索信息进行综合判断，本质上还是在处理临时信息，而不是庞大的记忆
      2. 大量的人类知识和语言能力都存储在了LLM模型的权重里面，对于这部分能做到类似人脑的处理能力，而且因为模型规模庞大，在知识范围方面超过了单个人类。但是只能用于存储成规模的大众通用的知识，而不能存储专业的私有信息知识，或者是个人的笔记
    3. LLM关于记忆
      1. 不能通过无限的在线上下文（kv cache）来实现记忆：效率太低
      2. 需要在背景持续对大量的记忆进行加工，整理，总结出规律和抽象，提升记忆检索和使用的效率
  4. 相关的尝试
    1. 人工结合蒙特卡洛搜索算法
      1. 微软rStar-Math：只是局限于对CoT的知识进行记忆
      2. AlphaGo：人工算法选择特定的权重，从而选择特定的记忆
    2. Tool-Integrity Reasoning （TIR）

记忆的信息分类

  1. 规则、约束
    1. xxx应该是xxxx
    2. xxx是xxxx
  2. 逻辑、推论
    1. 如果xxx则xxxx
    2. xxx那么xxx
  3. 现象、动作、陈述
    1. 吃饭
    2. 车开起来了

记忆的组织

  1. meaning tree
    1. 句子、单词级别
    2. 需要存储非常大的信息量，可能需要直接存储到模型权重
    3. 需要比较高级的抽象能力，当前LLM不具备，很多表示不能用语言表达
    4. 需要进行微调、训练
  2. 总结、类似脑图
    1. 段落级别
    2. 可以存储在传统数据库
    3. 可以通过prompt实现

记忆的操作

  1. 六种基本记忆操作：
    1. 巩固（Consolidation）
      1. 反复训练、推理、更新
      2. 修复不正确的、有矛盾的记忆，维持自洽
    2. 更新（Updating）
    3. 索引（Indexing）
      1. 对已有知识的联想、推理
      2. 深度、广度和效率是效果的重要指标
    4. 遗忘（Forgetting）
      1. 删除长期不用的、孤岛记忆、有矛盾的记忆
    5. 检索（Retrieval）
    6. 压缩（Compression）
      1. 对已经存在的记忆进行抽象，提取更高级的概念，重新组织记忆的表达形式
      2. 语义压缩，能够高效地组织知识、迅速地对世界进行分类
      3. 抽象的合理性
  2. AI中的记忆表示划分为
    1. 参数化记忆
      1. 在权重中，通过梯度下降进行改变
      2. 黑盒，难以进行精确的操作
    2. 上下文记忆
      1. 向量：KV cache等推理产生的中间值
      2. 非结构化上下文记忆：引用信息，视频
      3. 结构化的上下文记忆：指将记忆内容组织为预定义、可解释的格式或结构（如知识图谱、关系表或本体）
        1. 具备可查询性和符号推理能力
        2. 既可以在推理时动态构建以支持局部推理，也可跨会话持久保存高质量知识。

LLM实现记忆实现方法

  1. LLM大模型的权重
    1. 能进行一定深度和广度的处理能力，但是整体深度还是达不到人脑
    2. 需要通过及其复杂的梯度下降，不能快速存储特定数据，更新困难、无法追溯
    3. 黑盒，不确定性高
    4. 计算资源消耗大，虽然有MoE
  2. KVCache 等运行态中间变量
    1. 存储密度比较低，存储容量上限低
      1. 相对于权重表示，KVCache依赖自然语言的token，表达能力（复杂抽象不能用语言表达）和效率都比较差
    2. 逻辑推理能力稍差，思维能力稍差
      1. CoT可能出现前后矛盾的表达，长上下文之后，模型的准确性下降
    3. 计算资源消耗稍大
      1. 潜式思维链（Latent Chain-of-Thought）是一个改进方向
  3. 外部专用数据存储系统
    1. 容量大
    2. 抽象层级最低，存储密度最低，能力差
    3. 资源消耗小

需求本质

  1. 记录一段信息

    1. 格式化，向量化...

  2. 记录信息之间的关系

    1. 拓扑，树形，网状，点对点
    2. 逻辑关系，等价，推导，相似性的程度
    3. 本地的逻辑推理最为最高层的抽象，最核心的算法体现
      1. 不会因为不同的内容而改变，任何情况下总是可以正确的运行
      2. 拼接关键词，生成prompt

  3. 对信息进行拆分和组合和推理

    1. 对多个表达一样意思的描述进行合并、整理
    2. 对有矛盾的描述进行处理，自洽推理
    3. 对信息进行探索性推理

  4. 对信息进行重新组织和总结

    1. 数据库存储所有的“片段”和标签
    2. 标签可以被LLM进行运算
    3. 数据库存储所有的标签之间的关系，片段和标签的关系

核心问题

  1. 重点不是存而是取和算
  2. 抽象
    1. 总结规律，形成代表符号
  3.  记忆的运算
    1. 比较、类比
    2. 转换
    3. 推理
  4. 记忆必须参与到训练的过程，促进思维能力
    1. 记忆和理解能力（逻辑能力，抽象能力）不断的相互促进才能不断提升能力

&&&&&&&&&&&&&&&&&&&&&&&&

梯度下降不能产生意识，思维链可以短暂得产生意识

效率、可追溯性与长期适应性之间取得有效平衡。

本质上，AI信息处理是

  1. 使用绝对正确的逻辑和推理，对外部引用的信息进行推导和整理
  2. 不会出错误
  3. 能详细展示推理的过程，每个信息的出处

Forward: input -> format -> meaning tree -> calculate -> meaning tree -> gen -> output

Learning: input -> format -> meaning tree -> calculate -> new meaning -> update meaning

系统一

基础meaning -> weight

经过微调的LLM利用基础meaning实现 format 和 gen 构建一批针对此任务的数据集 

系统二

  1. 方案1 专用的模型（算法）持续被训练（修改）（关注逻辑运算和抽象，不懂实际的含义）： meaning tree -> meaning tree
  2. 方案2 采用人工编写的规则（算法）+数据结构+数据库 进行运算
  3. 经过系统二的不断运行，能够正循环不断提升抽象质量，从而达到高通用性和自洽

RAG

RAG的过程

  1. 拆分文本成文本块
    1. 拆分算法：
  2. 使用嵌入模型进行向量化
    1. 对一段文本使用一堆维度很多的向量进行表示
  3. 存入向量数据库
  4. 对输入进行向量化
  5. 使用传统的向量距离计算算法进行向量数据库的检索
  6. 提取数据库的原文片段，整合成prompt，投喂给LLM打模型
  7. 对输出整理和提取

技术局限性

  1. 切片粗暴
    1. 简单分块算法 (如按段落或固定字数)
    2. 太小了没有全局信息，句子可能被截断, 影响上下文理解
    3. 太大了不能精确统计
  2. 检索不精准
    1. 向量匹配基于数字相似性, 不代表实际含义
      1. 向量本质上不能完全代表“语义”
      2. 本质上需要表示一段文本的 meaning tree
    2. 结果可能与提问无关
  3. 没有大局观
    1. 无法处理结构化数据或统计型问题
    2. 大模型难以从数据碎片中做出准确总结
  4. 不能进行复杂的逻辑推理和动态交互

向量检索方法

  1. 主流向量检索方法都是基于欧几里得距离设计，主要看“谁离你最近”；但有时AI其实更需要比较“语义相关性”，也就是最大内积、看谁最相似。

  2. 内积空间并不是一个严格意义上的“度量空间”。一个空间可以称之为“度量空间”，最重要的属性就是“三角不等式”（三角形中任意两边之和大于第三边，而任意两边之差小于第三边）。HNSW、NSG、SSG等state-of-the-art的向量检索算法之所以能如此高效，就是因为他们都利用了三角不等式对索引结构（图结构）进行了高效的裁剪。

    1. 一是把最大内积转换为最小欧式距离，进而可以用HNSW、NSG来解决
    2. 二是不进行空间转化，直接在内积空间进行检索

进阶方案

  1. 加入重排序模型
    1. 初步检索数据 -> 语义分析
    2. 重新排序, 提高检索精度
  2. 使用MCP Server连接传统的数据库
    1. AI操纵关系型数据库
    2. 解决结构化数据查询问题
  3. 超大上下文模型
    1. 直接拖入资料, AI进行检索
    2. 如JiminI2.0 Pro, 上下文窗口长达2000万token
  4. 知识图谱RAG GraphRAG
    1. LPG：labeled property graph
    2. 使用大模型+prompt 生成
      1. 识别
      2. 合并
      3. 使用固定程序拼接成图谱

GraphRAG

开源项目

  1. 微软的Graph RAG
  2. 蚂蚁开发了首个对外开源的Graph RAG框架，蚂蚁全自主的开源产品：DB-GPT[50] + OpenSPG[42] + TuGraph[46]

    1. 跨图谱零拷贝融合，连接数据孤岛：替代实现，不断推理，建立逻辑关系

    2. 深度语义上下文关联：替代实现高级抽象

    3. 知识符号化表示，与大模型双向驱动：

    4. SPG-Reasoner逻辑规则推理，通过谓词语义和逻辑规则来定义知识之间的依赖和传递

GraphRAG过程

索引构建过程
  1. 使用文本分段技术将文档进行分块
  2. 关系（LPG）提取，分析每个文本单元并提取图元素：实体、关系和协变量
    1. 把文本加上合适的prompt，喂给LLM，要求 LLM 提供简短的摘要来完成
    2. 实体消歧
    3. 协变量提取
  3. 图增强
    1. 理解图的拓扑结构，并进行分类
      1. 使用分层莱顿算法生成node group的层次结构
    2. 使用 Node2Vec算法生成图中节点的向量表示。使我们能够理解图的隐式结构，并提供额外的向量空间，以便在查询阶段搜索相关概念
  4. node group 总结 -- 总结和推理出额外的信息
    1. LLM 生成每个社区（node group）的摘要
      1. 能够了解每个社区中包含的独特信息，并从高级或低级角度提供对图表的范围理解
      2. 这些报告包含执行概述，并引用社区子结构中的关键实体、关系和声明
    2. 生成社区报告、社区报告摘要和社区报告标题的文本嵌入来生成社区的向量表示
  5. 文件处理
    1. 链接到已经存在的TextUnits
      1. 将每个文档链接到第一阶段创建的文本单元，创建文本块之间的上下文关系
      2. 了解哪些文档与哪些文本单元相关
    2. 文档嵌入
      1. 使用文档切片的平均嵌入来生成文档的向量表示
      2. 对不重叠的块重新分块文档，然后为每个块生成嵌入
      3. 创建这些块的平均值，并按标记计数加权，并将其用作文档嵌入
      4. 能够理解文档之间的隐式关系，并帮助生成文档的网络表示
  6. 网络可视化
    1. 对于每个逻辑图，执行 UMAP降维以生成图的 2D 表示
查询过程
  1. 本地搜索
    1. 从低层级的节点开始搜索指定最大结果数量
    2. 使用向量查询关键Node和相关的Node
      1. MapReduce
    3. 问题+搜索到的原文+总结性描述 一起打包发给LLM
  2. 问题生成
  3. 全局搜索
    1. 从高层级的总结（node）开始搜索指定最大结果数量

缺点

  1. 关系太简单、固定，不能真正表达复杂的内含关系
    1. 关系的种类太少，只能识别简单的类似“A是B”的逻辑关系
    2. 关系的处理的深度太浅，广度太窄
    3. 只能处理自然语言能够表达的逻辑，不能处理非常抽象的概念
  2. 根据已经有的资料库总结和推理出额外的信息的能力不够
    1. 抽象的级别不够高级
  3. 只能处理已经写好的（prompt）里面的逻辑关系
    1. 不能自动不断积累（增加）需要分析的逻辑关系、能力
  4. 不能根据实际内容进行有目的的动态索引
    1. 按照固定算法搜索匹配数据库，不能根据实际逻辑关系动态控制
  5. 效率低
    1. 信息爆炸，需要处理的token非常庞大，导致速度非常慢
  6. 回答的风格和具体的模型非常相关
    1. 好的，用户让我用中文解释“xxx”
    2. ### xxx的定义与核心内涵  ### xxx的技术实现路径  ### xxx的协同创新维度  ### 总结与展望

待解决

  1. 符合需求的数据集
    1. 数据集难以构建和被准确得评估
      1. 通过对数据集得label进行打分，分数是一个可以被量化的指标
  2. 逻辑操作的种类很多，prompt放不下
  3. 基础设施的完善
    1. 图数据库，向量数据库
    2. 逻辑规则推理Reasoner