挑战
现有的 RAG 解决方案在注重隐私和以开发者为中心的使用场景中存在显著局限性：
- 外部 API 依赖 — 大多数 RAG 工具需要将文档内容发送到基于云的 embedding API，这违反了隐私要求
- 有限的格式支持 — 解决方案通常只处理纯文本或 PDF，而忽略了电子表格、Word 文档、HTML 和 Markdown
- 分块不佳 — 简单的文本拆分忽略了文档结构（页面、工作表、标题），创建了上下文贫乏的块
- 关键词缺失 — 纯粹基于 embedding 的搜索错过了词法搜索可以捕捉到的精确关键词匹配
- 电子表格处理盲区 — RAG 系统无法处理结构化表格数据或回答过滤/聚合查询
- 无重排序 — 初次检索通常只显示部分相关结果，缺少二次质量过滤
我们的解决方案
我们构建了一个完整的本地优先 RAG 系统，该系统具有多格式文档摄取、结构感知分块、本地 embedding 生成、混合搜索管道（语义 + 全文 + 新近度）、交叉编码器重排序以及基于 Web 的 UI — 所有这些都完全在用户机器上运行。
架构
- 文档加载器：针对 PDF, DOCX, XLSX, CSV, HTML, Markdown 和纯文本的特定格式解析器
- 分块器：结构感知的拆分，保留页面、工作表和标题边界
- Embeddings：通过 Transformers.js 实现的本地 embedding 模型（无外部 API 调用）
- 向量数据库：LanceDB（无服务器，基于文件）用于 embedding 存储和相似性搜索
- 全文搜索：基于 Trigram 的索引，用于词法匹配
- 重排序器：用于上下文感知结果评分的交叉编码器模型
- 查询分析器：在语义查询和结构化查询之间进行意图检测路由
- Web 服务器：带有项目管理和搜索端点的 Express.js API
- 前端：用于文档上传、管理和交互式搜索的基于 Web 的 UI
文档处理管道
多格式加载器
注册表模式自动检测文件类型并路由到相应的解析器：
- PDF — 文本提取与页面级分割
- Word (.docx/.doc) — 标题感知解析，保留文档层次结构
- Excel/CSV — 逐工作表解析，带标题检测和行级内容
- HTML — 标签感知提取，保留结构
- Markdown — 基于标题的分段解析
- 纯文本 — 基于行的分割
每个加载器除了内容外，还提取元数据（标题、作者、创建日期、页面/工作表数量、字数），生成带有源引用的结构化部分。
结构感知分块
与简单的文本拆分不同，分块器尊重文档边界：
- 保留分页符（PDF）、工作表边界（电子表格）和标题层次结构（Word/Markdown）
- 基于 token 的大小调整，具有可配置的分块大小和重叠
- 分层回退：首先按章节拆分，然后按段落，最后按句子
- 每个块都保留源元数据（页码、工作表名称、标题）以供归属
Embedding 与索引
本地 Embedding 模型
- 通过 Transformers.js 完全在本地运行 — 数据不会离开机器
- 量化模型，用于性能优化
- 批量 embedding，用于高效批量处理
- 在单词边界处自动截断，并进行 L2 归一化
向量存储
LanceDB 提供无服务器向量存储：
- 基于文件（无需单独的数据库服务器）
- 按项目隔离，具有独立的索引
- 基于 SHA256 的缓存键，用于去重
- 元数据与向量一起存储，用于过滤检索
混合搜索管道
检索管道结合了三种排序信号，以获得比任何单一方法更好的结果：
信号 1：Embedding 搜索（语义）
向量相似性搜索查找具有相关含义的块，即使使用了不同的词语。处理意译、同义词和概念查询。
信号 2：全文搜索（词法）
基于 Trigram 的索引与 Jaccard 相似度捕捉到 embedding 搜索可能遗漏的精确关键词匹配 — 这对于技术术语、名称和标识符很重要。
信号 3：新近度提升
指数衰减加权偏爱最近访问或修改的文档，确保最新信息首先浮现。
分数组合
信号与可配置的权重（默认：50% 语义，25% 词法，25% 新近度）相结合，进行归一化，并按最小分数阈值过滤。
交叉编码器重排序
初步检索后，交叉编码器模型对顶级候选进行重新评分：
- 上下文感知评分，同时考虑查询-文档对（而非独立考虑）
- 术语重叠的关键词提升计算
- 混合评分（交叉编码器 + 关键词信号）
- 生成比单独初次检索具有更高精度的最终排名列表
结构化数据支持
对于电子表格内容，系统提供额外功能：
- 自动检测列类型（数字、日期、布尔、字符串）
- 自然语言过滤（例如，“工程部门中薪资高于阈值的员工”）
- 聚合支持（计数、求和、平均值、最小值、最大值）
- 查询分析器将结构化查询路由到专用引擎，而不是 embedding 搜索
Web 界面
- 项目管理 — 创建、更新和删除知识库项目
- 文档上传 — 拖放文件上传，支持格式自动检测
- 文档创建 — 直接在 UI 中从文本创建文档
- 交互式搜索 — 带有排名结果的自然语言查询界面
- 统计数据 — 每个项目的索引大小、文档数量和格式分布
主要功能
- 完全本地化 — 所有处理都在设备上进行；没有针对 embeddings 或搜索的外部 API 调用
- 9 种输入格式 — PDF, DOCX, DOC, XLSX, XLS, CSV, HTML, Markdown, 纯文本
- 结构感知分块 — 将页面、工作表和标题保留为分块边界
- 混合搜索 — 结合语义、词法和新近度信号以实现更好的检索
- 交叉编码器重排序 — 二次评分以获得更高精度的结果
- 结构化查询 — 对电子表格数据进行自然语言过滤和聚合
- 无服务器向量数据库 — LanceDB 基于文件的存储，无基础设施开销
- 文档写入 — 支持 PDF, DOCX 和 XLSX 创建的导出功能
- 项目隔离 — 具有独立索引的知识库
- Web UI — 用于文档管理和交互式搜索的完整界面
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
常见问题
MicrocosmWorks 构建了一个本地优先的RAG系统，其中所有的文档摄取、嵌入生成、向量存储和LLM推理都完全在您的基础设施上运行，而无需向外部云API发送任何数据。这种架构对于处理机密文档、律师-客户特权材料或敏感知识产权的组织至关重要，因为数据主权要求禁止任何云端处理，即使通过加密也是如此。
MicrocosmWorks 实施了一个混合检索管道，该管道并行运行 BM25 关键词搜索和密集向量语义搜索，然后使用倒数排序融合来合并并重新排序组合结果，再将其作为上下文传递给 LLM。这种方法可以捕获语义搜索会遗漏的精确匹配查询，例如产品代码和法律引文，同时也能检索到关键词搜索永远找不到的概念相关内容。
MicrocosmWorks 构建了针对 PDF、DOCX、XLSX、PPTX、HTML、Markdown 和纯文本的特定格式解析器，并使用 Tesseract 构建了用于扫描 PDF 和基于图像文档的 OCR 流水线。该系统自动检测 PDF 是否包含可选文本或需要 OCR，应用布局分析以保留表格结构和阅读顺序，并使用语义边界而非任意字符限制来分块文档，以提高检索质量。
MicrocosmWorks 实施了增量索引，该索引跟踪文档校验和，并且只重新处理自上次摄取运行以来发生更改的文件。更新的文档会删除其旧数据块并原子地插入新数据块，因此搜索索引永远不会处于不一致的状态。该系统还支持版本化文档检索，允许用户在需要进行审计或合规性检查时查询文档的历史版本。
MicrocosmWorks 优化了本地 RAG 管道，使其能够在适度的硬件上运行，最低推荐配置为一台具有 32GB RAM、8 个 CPU 核心的机器，并可选择配备一个中档 GPU 用于加速嵌入生成。对于没有 GPU 硬件的组织，系统将回退到基于 CPU 的嵌入模型，但延迟会略高，并且矢量数据库针对 SSD 存储进行了优化，以确保在多达 100 万个文档块的数据集上，查询响应时间保持在 200ms 以下。