调研报告

前期个人调研报告

项目简介

更强大的文件系统 Agent。支持使用自然语言进行文件操作，用图形式重新组织文件，提升增删查改等操作的效率。

项目背景

近年来，AI，尤其是 LLM 实现了快速发展和广泛应用。从 Chat Bot 到 AI Agent，LLM 的应用更加智能化和自主化，也更加需要与操作系统交互的能力。在这种背景下，AIOS 应运而生，为基于 LLM 的 Agent 提供高效的资源管理、调度和上下文维护能力。其架构如下：(mei2024aios)

AIOS Architecture

这张图展示了 AIOS 的分层系统架构，其结构自上而下分为三层：

应用层 (Application Layer):

Agent Application: 这是顶层，包含了各类具体的 AI 智能体应用（如旅行 Agent、推荐 Agent、编码 Agent、数学 Agent、叙事 Agent 等），均面向特定任务或领域。
AIOS-Agent SDK: 这是关键的中间件/接口层，直接服务于上层 Agent 应用，其主要作用有：
- 接收来自 Agent 应用的请求。
- 区分请求类型：
  - LLM 相关查询: 例如推理与规划、工具解析、代码生成等需要大型语言模型支持的请求，将被委托至 AIOS Kernel 处理。
  - 非 LLM 相关查询: 如传统的文件操作、网络请求、键盘/鼠标输入等，则交由标准 OS Kernel 处理。

内核层 (Kernel Layer):

这一层是系统的核心，包含了两个并行的内核组件：传统的 OS 内核和专门的 AIOS 内核。
OS Kernel:
- 包含标准操作系统的核心组件：进程调度器 (Process Scheduler)、内存管理器 (Memory Manager)、文件系统 (Filesystem)、硬件驱动 (Hardware Driver)。
- 负责管理系统的基本资源，处理来自应用层的非 LLM 相关请求，并直接与硬件交互（通过硬件驱动）。
AIOS Kernel:
- 这是为 AI Agent 和 LLM 设计的专用内核。
- AIOS System Call: 提供给 AIOS-Agent SDK 调用的接口，用于处理 LLM 相关的复杂任务。
- 核心组件：
  - LLM Core(s): 可能是指运行大型语言模型的核心引擎或处理器。
  - Agent Scheduler: 负责调度和管理各个 Agent 的执行。
  - Context Manager: 管理 Agent 执行所需的上下文信息。
  - Memory Manager: 管理 Agent 或 LLM 运行所需的内存资源，可能与 OS 的内存管理器有协作。
  - Storage Manager: 管理 Agent 运行所需的数据存储。
  - Tool Manager: 管理和协调 Agent 可以使用的外部工具或 API。
  - Access Manager: 控制 Agent 对资源和工具的访问权限。
- 与 OS Kernel 的交互: AIOS Kernel 需要通过 OS System Call 接口与底层的 OS Kernel 交互，以获取硬件资源（如通过 OS 内存管理器分配内存，通过文件系统读写磁盘等）。

硬件层 (Hardware Layer):

这是最底层，包含系统的物理硬件资源。
组件： CPU (中央处理器)、GPU (图形处理器，对 LLM 运算很重要)、Memory (物理内存)、Disk (磁盘存储)、Peripheral Devices (外围设备)。
硬件资源由内核层（主要是 OS Kernel 的 Hardware Driver）进行管理和抽象。

总之，AIOS 架构设计的核心思想是：

双内核设计：保留传统 OS 内核处理通用任务和硬件管理，同时引入一个专门的 AIOS 内核来高效、集中地管理 AI Agent 的生命周期、资源调度、LLM 调用、工具使用和上下文维护。
SDK 作为分发器：AIOS-Agent SDK 充当应用层和内核层之间的桥梁，智能地将不同类型的请求路由到合适的内核进行处理。
深度整合：将 AI 能力（特别是 LLM 和 Agent）作为操作系统内核级别的服务来提供，而不是仅仅作为上层应用，以期获得更高的效率和更好的资源管理。

在这个背景下，我们初步选择 LLM + FS 这个方向，以实现一个基于大模型的文件管理系统。

立项依据及相关技术

语义文件系统

传统的文件存储和检索主要依赖于系统维护的索引结构，其中文件元数据指向文件在磁盘上的位置。虽然优化索引结构可以提高检索效率，但这些传统的存储模型仍然在很大程度上依赖于从文件内容中提取的关键字。Gifford 等人（gifford1991semantic）率先提出了语义文件系统。他们引入了一个中间层，该层通过从文件中提取属性来生成目录，使用户能够更便捷得通过导航查询文件属性。（eck2011semantic）提出了一个严谨的语义系统，并设想基于此来管理数据。随后的许多工作都尝试利用语义来降低查询的消耗。

基于此，我们设想将语义信息与图形的文件系统设计相结合，以提供可扩展的搜索和导航，并且尝试通过这种想法构建一个全新的文件组织形式——图文件组织方式。

另一方面，Bloehdorn 等人（bloehdorn2006tagfs）提议通过语义标签来管理文件。Schandl 等人（schandl2009sile）也尝试开发了一种使用语义词汇管理桌面数据的方法。

相比之下，我们想要实现的 LLM + FS 的文件系统将借助 LLMs 的强大语言理解能力来实现，这将大大降低传统做法中，对于语义这一概念的相关功能实现。此外，我们还可以集成文件系统各个方面的语义信息，这一做法带来的全面性可以增强系统理解和管理文件的能力，如果能够真正实现这一想法，理想中这将大大改进早期语义文件系统能够提供的功能。

元语义解析

如何将用户通过自然语言描述的需求转化为计算机能够执行的命令，是我们的项目乃至整个 AIOS 非常重要的基础。这里就涉及到了语义解析的相关工作。

语义解析器的目标是将自然语言转换为机器可解释的格式。早期的工作主要集中在将自然语言转换为 SQL 查询或其他形式的逻辑表达式。前者至今仍有新的进展，如 Text-to-SQL。

过去很长一段时间研究人员还致力于开发专门的语义解析器（kamath2018survey），它旨在尝试将自然语言转换为机器可解释的格式。

随着深度学习的发展，研究人员也开始探索使用神经网络来进行语义解析。但是，以上的这些方法在处理复杂的语义和看不见的自然语言方面都存在限制，其中基于深度学习的方法又存在训练成本。

如今，我们有了一个非常强大的工具-LLM, 在 LLM 强大的语义理解能力的帮助下，我们可以通过提示词工程让 LLM 按照格式限制生成更加机器友好的指令文本 (例如去年 ArkFS 的实现方法), 然后解析指令文本，调用普通的操作系统 API 完成任务了：

lsfs parser

相比以往的元语义解析器的工作，我们计划以 LLM 强大的自然语言理解能力作为基础。这将提高文件系统对于自然语言需求的理解能力。

检索增强生成（RAG）

基本介绍

RAG（Retrieval Augmented Generation）为生成式模型提供了与外部世界互动提供了一个很有前景的解决方案。RAG 的主要作用类似搜索引擎，找到用户提问最相关的知识或者是相关的对话历史，并结合原始提问（查询），创造信息丰富的 prompt，指导模型生成准确输出。其本质上应用了 In-Context Learning 的原理。

RAG 可分为 5 个基本流程：知识文档的准备；嵌入模型（embedding model）；向量数据库；查询检索和生产回答。

基础 RAG 的实现大致可以分为内容索引阶段和检索生成阶段。

在内容索引阶段，我们需要将知识文档中的信息切分成小段，然后利用某种 Transformer 编码器模型，将这些文本段转换成向量形式。接着，把所有向量汇集到一个索引里。最后，为大语言模型（Large Language Model, LLM）制定一个提示词，这个提示词会指导模型根据我们在搜索步骤中找到的上下文信息来回答用户的查询。

在检索生成阶段，我们会用同一个编码器模型把用户的查询转换成向量，然后根据这个向量在索引中进行搜索。系统会找到最相关的前 k 个结果，从数据库中提取相应的文本段，然后把这些文本段作为上下文信息输入到大语言模型的提示词中。

嵌入

因此，从语义信息到向量空间的嵌入操作是 RAG 最重要的部分之一。嵌入通常指的是将现实世界的事物映射到多维空间中的向量的方法。例如，我们可以将图像映射到一个 n x m 维度的空间中，如果映射足够好，两个图像之间的距离可以反映它们的相似性。

嵌入的另一个例子是 word2vec 算法，它将每个单词都映射到一个向量中。例如，如果嵌入足够好，我们可以对它们进行加法和减法操作，可能会得到以下结果：

vec ("apple") + vec ("pie") \approx vec ("apple pie")

也可以表达为：

| vec ("apple") + vec ("pie") - vec ("apple pie") | \approx 0

类似地，"pear" 应该比 "dinosaur" 更接近 "apple"：

| vec ("apple") - vec ("pear") | < | vec ("apple") - vec ("dinosaur") |

有了这个基础，理论上我们可以搜索与给定问题更相关的书籍片段。基本过程如下：

将书籍分割为小片段，为每个片段创建嵌入并存储它们
当有一个问题时，计算问题的嵌入
通过计算距离找到与书籍片段最相似的前 K 个嵌入
使用问题和书籍片段构建提示
使用提示查询 LLM

高级 RAG 技术

为了进一步优化该模型，研究者提出了很多高级 RAG 技术。在思考 RAG 在文件系统应用的优化时，我们想到了工业界已经存在的层次索引方案：创建两个索引，一个由摘要组成，另一个由文档块组成，然后分两步进行搜索：首先通过摘要过滤出相关文档，接着只在这些相关信息内进行搜索。如下图所示：

除此之外，我们还调研得到了分块向量化、假设性问题和 HyDE、上下文增强等 RAG 的优化方案。但最终引起我们注意的是将 RAG 与图结构结合起来的 Graph RAG 技术。

Graph RAG：与图结构的结合

1743232430272

在利用 RAG 进行知识文献查询整理时，研究者注意到了一些问题。比如用户查询“告诉我所有关于苹果和乔布斯的事”，并要求基于《乔布斯自传》进行问答时，这个问题涉及到的上下文大量分散在自传这本书不同的 30 页中。传统的“分割数据，Embedding 再向量搜索”方法在多个文档块里用 TOP-K 去搜索的方法很难得到这种分散，细粒的完整信息，而且还很容易遗漏互相关联的文档块，从而导致信息检索不完整。

尽管 RAG 在文本数据上表现优异，但对于结构化数据（如知识图谱），传统的 RAG 方法显得力不从心。知识图谱（KGs, Knowledge Graphs）等图结构数据蕴含丰富的关联信息，而 GraphRAG 则专门用于从图数据中检索信息。然而，随着研究的深入，人们发现将文本数据转化为图结构后，GraphRAG 在文本任务中也能发挥重要作用。例如，在社交网络分析中，GraphRAG 可以通过分析用户之间的关系，帮助识别潜在的社交圈层。

图能够编码大量的异构和关系信息，很契合众多现实世界应用，将 Graph 与 RAG 结合得到的 Graph RAG 方法获得了越来越多的关注。

知识图谱

知识图谱这个术语最初由谷歌在 2012 年 5 月提出，作为其增强搜索结果，向用户提供更多上下文信息的一部分实践。知识图谱旨在理解实体之间的关系，并直接提供查询的答案，而不仅仅返回相关网页的列表。

知识图谱是一种以图结构形式组织和连接信息的方式，其中节点表示实体，边表示实体之间的关系。图结构允许用户高效地存储、检索和分析数据。这类知识图谱的结构有助于解决文档分割与嵌入的问题。

GraphRAG 管线

GraphRAG 框架由以下关键组件构成：

查询处理器（Query Processor）：负责预处理用户定义的查询，使其能够与图数据源进行交互。
检索器（Retriever）：根据预处理后的查询从图数据源中检索相关内容。
组织者（Organizer）：对检索到的内容进行整理和优化，以提高生成器的性能。
生成器（Generator）：根据组织后的信息生成最终答案。

由此，一个简单的 Graph RAG（的用户端）可以如下去简单实现：

使用 LLM（或其他）模型从问题中提取关键实体。
根据这些实体检索子图，深入到一定的深度。
利用获得的上下文利用 LLM 产生答案。

用 GraphRAG 从海量知识中组织图结构，并响应用户查询的全部流程可以用下图表示：

Graph RAG Approach: Microsoft Research

GraphRAG 的优势与挑战

优势

与传统 RAG 相比，Graph RAG 的主要优势在于它能够检索有关查询中提到的实体的全面详细信息。Graph RAG 不仅获取有关查询实体的详细信息，还标识并将其与其他连接的实体相关联。相比之下，标准 RAG 检索的信息仅限于特定文档块，更广泛的关系和联系捕获不足。

关系理解与推理：GraphRAG 能够通过图结构理解和推理实体之间的关系，这使得它在处理复杂关系查询任务时具备独特的优势。
知识图谱集成：GraphRAG 可以很自然地与知识图谱集成，通过知识图谱中丰富的关系信息来增强模型的生成和推理能力。

挑战

Graph RAG 的增强功能也有其自身的挑战。在我们调研到的一次实验中，作者提取了一个包含大约 83,000 个令牌的文件，这些令牌需要分块和嵌入。使用标准的 RAG 方法，使用大致相同数量的令牌创建嵌入。而当作者使用 Graph RAG 摄取同一个文件时，该过程涉及大量的提示和处理，产生了大约 1,000,000 个令牌——几乎是单个文件原始令牌计数的 12 倍。

图的构建与维护：构建和维护图结构的知识库成本较高，特别是对于涉及大量动态更新的数据，维护图的结构和一致性是一个挑战。
计算复杂度：当图的节点和边数较多时，检索过程的复杂度将显著增加，可能导致性能下降。

分布式文件系统

分布式文件系统（Distributed File System，DFS）是一种文件系统，它的物理存储资源并不直接连接在本地节点上，而是通过计算机网络与节点相连，或者是将若干不同的逻辑磁盘分区或卷标组合在一起，形成一个完整的有层次的文件系统。这种系统为分布在网络上任意位置的资源提供一个逻辑上的树形文件系统结构，使用户访问分布在网络上的共享文件更加简便。

主要特点

数据分散存储：分布式文件系统将大量数据分散到不同的节点上存储，大大减小了数据丢失的风险。这种冗余性使得部分节点的故障并不影响整体的正常运行，即使出现故障的计算机存储的数据已经损坏，也可以由其它节点将损坏的数据恢复出来。
高可扩展性：分布式文件系统通过网络将大量零散的计算机连接在一起，形成一个巨大的计算机集群，使各主机均可以充分发挥其价值。此外，集群之外的计算机只需要经过简单的配置就可以加入到分布式文件系统中，具有极强的可扩展能力。
高可靠性：分布式文件系统具有冗余性，部分节点的故障并不影响整体的正常运行。即使出现故障的计算机存储的数据已经损坏，也可以由其它节点将损坏的数据恢复出来。

常见的分布式文件系统

GFS（Google File System）：一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS 虽然运行在廉价的普遍硬件设备上，但依然提供灾难冗余的能力，为大量客户机提供高性能的服务。
HDFS（Hadoop Distributed File System）：HDFS 是 Hadoop 的专用文件系统，允许使用简单的编程模型跨计算机集群分布式处理大型数据集。
Ceph：一个基于 POSIX 的没有单点故障的分布式文件系统，使数据能容错和无缝的复制。
Lustre：一个开源、分布式并行文件系统软件平台，具有高可扩展、高性能、高可用等特点。

未来发展方向

随着 5G、AI、云技术的快速普及和发展，数据的产生呈几何级数增长，必然会带来更大的挑战，势必会催生出下一代分布式文件系统。未来的分布式文件系统需要解决的问题包括数据的多元化存储、更灵活的适用场景、系统的性价比提升、更强的适用性和更方便的运维等。

前瞻性/重要性分析

我们创新地将基于 LLM 的文件系统、大语言模型的 Graph RAG 技术和图文件系统相结合，从而得以协同发挥各自的优势。

通过语义构建数据组织层次，优化数据局部性。与以往基于存储位置组织文件的形式相比，图的结构能更准确地表示文件之间的相似特征与依赖关系。通过 LLM 提取语义特征以整理出知识图谱，文件系统能够更好地整理强相关的文件，从而更好地利用存储设备的局部性特征。
灵活的语义标签与多维分类。基于图的文件系统允许为文件附加多维度的语义标签，支持多对多的关系映射。这种灵活性使用户能够根据不同的语义维度对文件进行分类和检索，超越了传统树状结构的单一分类方式，提供了更直观和多样化的文件组织方式。
更强的关系理解与推理能力。与以往得到 AIOS 实现相比，基于 GraphRAG 构建的文件系统能够检索有关查询中提到实体的全面详细信息，通过图结构理解和推理实体之间的关系，在处理资料整理、依赖分析等复杂查询任务时具备独特优势。
知识图谱集成，高效存储、检索和分析数据。Graph RAG 构建的知识图谱有助于更高效、准确地将文件特征及用户查询输入映射至多维空间，更细、更小地切割数据颗粒度，还可以从现有的知识图谱中进行上下文学习，与其他索引结合使用，具有比其它结构化数据更高的信息密度。

在人工智能飞速发展的浪潮中，AIOS 的概念以及 LLM 与文件系统的深度融合，代表了计算范式演进的关键方向，具有极其重要的前瞻意义。
考虑到 LLM + FS 从逻辑上讲属于 AIOS 的一部分，我们首先来分析 AIOS 这一想法本身的重要性与前瞻性：
- 资源优化与效率提升：AIOS 有望像传统 OS 管理 CPU、内存一样，对 GPU、NPU、LLM 推理核心、Agent 上下文等 AI 特有资源进行统一、高效的调度和管理。通过专门的 Agent Scheduler、Context Manager 等组件，可以显著提升多 Agent 并发执行效率，优化昂贵计算资源的利用率，减少冗余开销。
- 标准化与生态构建：AIOS 及其 SDK 将为开发者提供一套标准的接口和环境来构建、部署和管理 AI Agent。例如现在 Anthropic 公司提出的 MCP 协议，其在应用层面设计了一套规范化的协议，使得未来开发者在进行 LLM 相关开发时能够极大降低开发门槛，促进 Agent 应用生态的发展，实现不同 Agent 之间的互操作性和协作。
- 面向未来的架构：随着 AI Agent 变得更加自主、复杂和无处不在，一个专门为其设计的操作系统层将是必然趋势。AIOS 作为一个操作系统，如果能够被完善，那么未来完全可以基于 AIOS 重新设计一套计算机组成结构，使得 AI 能够更好的被运用。用于 AIOS 是支撑未来通用人工智能（AGI）或高度智能化的分布式 AI 系统运行的潜在基石架构。
而作为 AIOS 的一部分，LLM+FS 的重要性与前瞻性如下：
- 打破信息间的独立性：文件系统是现代计算中信息存储的基础结构。然而，传统的文件系统对于存储内容的“语义”是盲目的。LLM+FS 的融合，旨在赋予系统理解文件内容、结构和关联的能力。这意味着用户可以通过自然语言查询、操作和组织文件（例如，“查找我上周写的关于 AIOS 项目进展的报告”），极大提升信息检索和管理的效率与直观性。
- 解锁数据价值：大量的知识和数据沉淀在个人和组织的文件系统中。LLM + FS 能够让 LLM 直接“阅读”和“理解”这些本地或网络存储的数据，将其转化为可用的知识，进行内容摘要、信息抽取、跨文档分析等，从而盘活沉睡的数据资产。
- 实现更智能的自动化：结合 LLM 的推理和生成能力，LLM + FS 在未来可能实现更深层次的文件系统自动化，如根据内容自动分类归档、基于项目需求生成代码或文档框架并存入指定位置、监控文件变化并触发相应工作流等。
- 构建本地 Agent 的长期记忆与工作空间：由于硬件的限制，如今人们使用高性能的 LLM 或是 AI 工具，更多地是调用远端服务商提供的服务。而在未来，如果个人计算机的硬件能力发展到能够本地运行足够强大的 AI 工具，那么此时将会涉及到"长期运行"和"积累知识"这两大问题。此时，基于 LLM 开发的文件系统可以作为其可靠的外部“记忆体”和“工作空间”。LLM + FS 的集成使得 Agent 能够更自然、高效地利用文件系统来存储、检索和组织其工作所需的信息和状态。
总的来说，AIOS 和 LLM + FS 展示了将 AI 能力深度融入计算基础设施的可能路径。作为 AIOS 的一部分，LLM + FS 聚焦于数据组织与交互层面，让 AI 能够理解并赋能最基础的信息存储单元。它们的具体实现，预示着一个更加智能、高效、自然的未来计算形态——AI + 操作系统。它本身就具备强大的认知和协作能力，用户与信息的交互方式将被彻底革新。这些工作不仅是技术上的前沿探索，更是推动 AI 从"工具"进化为"伙伴"和"基础设施"的关键一步，其长远价值和影响力不可估量。