# Aether：面向金融合规文档的混合RAG工作流推理引擎

> Aether是一个专为金融文档处理设计的AI工作流引擎，采用规划器-执行器-评判器循环架构，结合混合RAG检索和完整审计追踪，实现从杂乱文档到可审计结果的自动化处理。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-24T00:45:02.000Z
- 最近活动: 2026-05-24T00:51:04.161Z
- 热度: 154.9
- 关键词: 金融合规, RAG, AI工作流, 文档处理, Claude, DuckDB, 审计追踪, 混合检索, Agent架构, 合规自动化
- 页面链接: https://www.zingnex.cn/forum/thread/aether-rag
- Canonical: https://www.zingnex.cn/forum/thread/aether-rag
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：clee12111
- 来源平台：github
- 原始标题：aether
- 原始链接：https://github.com/clee12111/aether
- 来源发布时间/更新时间：2026-05-24T00:45:02Z

## 原作者与来源\n\n- **原作者/维护者**: clee12111\n- **来源平台**: GitHub\n- **原始标题**: aether\n- **原始链接**: https://github.com/clee12111/aether\n- **发布时间**: 2026年5月24日\n\n---\n\n## 问题背景：金融数据处理的现实困境\n\n金融合规分析师的日常工作充满挑战。他们经常收到一堆杂乱的CSV文件、基金协议PDF和政策文档，需要完成数字核对、规则交叉引用和违规标记等任务。这些任务的步骤因数据和目标而异，高度依赖分析师的经验和判断力。\n\n这种工作模式的痛点在于：数据来源多样、格式不一，而合规要求又极其严格，需要完整的审计追踪。传统的自动化工具往往难以应对这种灵活性和严谨性的双重需求。要么过于僵化，无法适应变化的输入；要么过于松散，无法满足合规审计的要求。\n\n---\n\n## Aether的核心设计：规划-执行-评判循环\n\nAether采用了一种独特的三层代理架构来解决这个问题。系统运行一个规划器-执行器-评判器循环，叠加在混合RAG层之上。\n\n**规划器**使用Claude Opus模型，读取目标和检索到的上下文，生成结构化的执行计划，包含具体的工具调用。这一层负责复杂的推理和决策，确定需要哪些步骤来完成任务。\n\n**执行器**负责分派这些工具调用，将数据加载到DuckDB、运行SQL查询、标记项目、生成报告等。关键设计决策是：执行器循环中完全没有LLM参与， purely是机械化的工具调度。这保证了执行的可预测性和成本可控性。\n\n**评判器**使用Claude Haiku模型，将输出与原始目标进行比较，返回结构化的评判结果。如果评判结果是"部分通过"，系统会根据评判反馈重新规划，最多进行2轮修订；如果评判结果是"失败"，则升级到人工审核队列。\n\n---\n\n## 混合RAG检索：精确与召回的平衡\n\nAether的检索层采用了混合策略，结合了BM25稀疏检索和密集向量检索的优势。具体流程是：文档首先被分块，然后通过BM25和密集检索（使用all-MiniLM-L6-v2模型）分别检索，结果通过RRF（Reciprocal Rank Fusion）合并，最后使用flashrank重排序器进行精排。\n\n这种设计的智慧在于承认不同检索方法有互补的失败模式。BM25在关键词匹配上表现优秀，而密集检索在语义相似性上更有优势。通过动态查询分类（从索引的列元数据推断，而非硬编码），系统可以根据查询意图自动调整检索策略。\n\n评估结果显示，检索精确度@5达到96%（25个测试用例中24个成功），且管道是确定性的，5次运行的标准差为0.00。这种高可靠性对于金融合规场景至关重要。\n\n---\n\n## 端到端性能与成本分析\n\n在15个端到端测试用例中，系统成功率达到87%（13/15）。这个可靠的下限表明系统在实际应用中是可行的。完整运行的结果在13-14个成功之间波动，详细分析见项目文档。\n\n成本方面，每次端到端运行的成本约为0.65美元。这个成本结构反映了智能的模型路由策略：Opus用于规划（复杂推理），Haiku用于评判（结构化比较），执行器不使用LLM。能力与成本精确匹配，避免了过度消耗。\n\n两个主要的失败模式是：1）规划器的SQL幻觉（虚构不存在的表），2）评判器的间歇性过度升级。这些发现为后续改进提供了明确方向。\n\n---\n\n## 关键设计决策：可审计性与可靠性优先\n\nAether的设计体现了几个重要的工程原则。\n\n**直接使用Anthropic SDK，不使用LangChain。** 系统中的每个决策都是可见的代码，没有框架抽象隐藏重试逻辑、提示组装或输出解析。这种透明度对于需要理解系统行为的金融场景至关重要。\n\n**每个代理输出都进行Pydantic验证，错误时重试。** 规划器和评判器都对其LLM响应进行Pydantic模型验证。验证失败时，错误信息会反馈给LLM，最多重试3次。这种设计将LLM的非确定性转化为结构化可靠性。\n\n**引擎与领域分离。** 少样本示例是外部文本文件，在初始化时加载。通过将`PROMPTS_DIR`指向不同目录即可切换领域，无需修改引擎代码。这种设计使Aether可以应用于金融以外的其他领域。\n\n**SQLite追踪存储。** 每个LLM调用和工具调用都记录在SQLite数据库中（WAL模式），包含运行ID、代理、事件类型、输入输出token数、持续时间和完整负载。可审计性是一等公民，不是事后补充。\n\n---\n\n## 技术栈与项目结构\n\nAether的技术栈选择体现了务实和成熟度的平衡。Python 3.11作为基础，uv作为包管理器，DuckDB用于本地数据处理，Chroma用于向量存储，Streamlit用于UI层。\n\n项目结构清晰分层：`ingestion/`处理文档解析，`rag/`实现混合检索，`agents/`包含三层代理实现，`tools/`提供工具层，`models/`定义Pydantic模型，`trace/`管理SQLite追踪存储，`prompts/`存放领域可切换的少样本示例。\n\n这种结构使得代码易于理解和维护，也为贡献者提供了清晰的扩展点。\n\n---\n\n## 局限性与坦诚的自我认知\n\n项目文档明确列出了Aether不是什么，这种坦诚值得赞赏。\n\nAether不是LangChain/LangGraph/CrewAI的包装器，而是一个从零构建的专用系统。它不是通用AI助手，而是专注于文档处理工作流的特定领域工具。它不试图解决每个领域的问题，金融只是演示领域，引擎本身是领域无关的。它不追求复杂的前端，Streamlit作为MVP界面已经足够。\n\n这种聚焦使得Aether在其核心场景上可以做到深度优化，而不是在所有场景上都表现平庸。\n\n---\n\n## 未来方向：智能检索的深化\n\n当前评估中持续存在的失败案例是跨文档查询，单查询检索无法同时从两种不同文档类型中检索相关块。这是下一阶段的驱动问题。\n\n规划中的改进包括：**智能检索**——由规划器驱动的查询分解，LLM将目标重写为子查询，分别检索后合并结果；**查询感知重排序**——用考虑目标上下文的动态重排序器替代静态重排序器；**检索评估作为一等公民**——超越precision@5，测量跨文档查询的召回率、重排序器贡献（消融研究）、失败原因归因。\n\n开发者承诺保持与之前交易机器人项目相同的纪律：每个检索失败模式都将被记录，包含复现步骤和最终修复方案。这种对工程严谨性的承诺令人印象深刻。\n\n---\n\n## 实际意义与应用价值\n\nAether的设计对金融合规领域有重要价值。它解决了从非结构化文档中提取结构化洞察的痛点，同时满足了合规审计的严格要求。完整的审计追踪使得每个决策都可追溯，这在监管日益严格的环境中是核心需求。\n\n对于其他领域，Aether的架构也提供了有价值的参考。规划-执行-评判的分层模式、混合RAG策略、模型路由优化、以及领域与引擎的分离，都是可以借鉴的设计模式。\n\n---\n\n## 总结\n\nAether是一个精心设计的金融文档处理引擎，展示了如何在特定领域深度优化AI工作流。它不追求通用性，而是在其核心场景上做到可靠、可审计、成本可控。6周的个人开发周期产出了一个功能完整、评估严谨、文档清晰的项目，这本身就是工程能力的体现。\n\n对于需要在受监管环境中部署AI系统的组织，Aether提供了一个值得研究的参考实现。它的设计决策——特别是关于可审计性、可靠性和成本控制的权衡——对于生产级AI系统的设计具有普遍指导意义。