RAG on FXIO 技术博客

我把信息摄入、追踪、研究拼成了一条流水线：五个 GitHub 项目的组合拳

Tue, 04 Aug 2026 12:01:09 +0800

我把信息摄入、追踪、研究拼成了一条流水线：五个 GitHub 项目的组合拳

单个 AI 工具解决单点问题，但信息工作的真实形态是一条链：格式转换 → 聚合 → 追踪 → 研究 → 沉淀。本文拆解五个各管一段的开源项目，以及它们怎么拼成一条个人信息流水线。

先描述一个典型的信息工作日：早上要看行业新闻，盘中要盯持仓股票的异动，临时要调研一家公司近况，周末还要整理读书笔记。如果每件事都靠「打开 N 个网站 + 手动复制粘贴」，一天下来真正思考的时间所剩无几。

我在 GitHub 上找到的解法不是一个全能工具，而是五个各管一段的项目。它们串起来的逻辑是：数据先变成 LLM 能吃的格式，再被聚合和追踪，最后由 AI 加工成结论。

入口段：markitdown——一切格式转 Markdown

微软的 MarkItDown 解决的是流水线最脏最累的第一环：把任意文档变成 LLM 友好的文本。

PDF、Word、Excel、PPT、图片、音频、HTML、CSV，甚至 zip 包和网页 URL，一行命令转成结构清晰的 Markdown。它和普通文本提取工具的关键区别：保留标题层级、表格结构和列表语义，而不是把文档拍平成一坨纯文本——下游模型能不能理解文档结构，差距就在这。

架构是「转换器注册表」：核心类维护 MIME 类型到 Converter 的映射，每种格式一个转换器（pdfminer 管 PDF、python-docx/pptx/openpyxl 管 Office 三件套），可选挂 OCR、Whisper 转写、LLM 图片描述。已经有 AutoGen 和 LangChain 的官方集成。

向量检索太吃内存？turbovec 可能是你在找的东西

Tue, 09 Jun 2026 23:00:00 +0800

背景

最近在搞 RAG 相关的东西，向量数据库这块一直用的 FAISS。用着没啥大毛病，但有个痛点：内存占用太大。

1000万条 1536 维的向量，float32 存储直接干到 31GB。服务器内存吃不住，量化方案又得单独跑 train 阶段，数据量小了码本质量还拉胯。

然后在 arXiv 上刷到一篇 Google Research 的论文——TurboQuant（ICLR 2026），顺着论文找到了它的 Rust 实现：turbovec。

试了一下，真香。

turbovec 是什么

一句话：基于 TurboQuant 算法的向量索引库，Rust 写的，有 Python 绑定。

核心卖点：

1000万 1536 维向量，31GB → 4GB
没有 train 阶段，add() 直接索引
比 FAISS IndexPQFastScan 快 12-20%（ARM）/ 持平或略快（x86）
纯本地，数据不出机器

GitHub: RyanCodrai/turbovec（9K+ stars）

技术原理（简化版）

TurboQuant 的核心思路挺巧妙的：

归一化：把向量长度去掉，变成超球面上的单位方向
随机正交旋转：旋转之后，每个坐标独立服从已知的 Beta 分布。关键点——这个分布跟输入数据无关，是数学上能推导出来的
Lloyd-Max 量化：既然分布已知，最优的桶边界可以直接算出来，不需要从数据里学
Bit-pack：1536维向量从 6144 字节压到 384 字节，16 倍压缩

省掉了 train 阶段，意味着：

数据量小也能用
在线添加新向量不需要重建索引
没有超参数调优的烦恼

实际用法

pip install turbovec

基础用法真的很简单：

RAG 检索增强生成

Mon, 23 Mar 2026 01:26:31 +0800

一、什么是 RAG？

RAG 全称是 Retrieval-Augmented Generation（检索增强生成）。

为了理解它，我们需要先了解大语言模型（LLM）的两大痛点：

知识滞后性：大模型的训练数据截止于某个时间点，对于训练后发生的新闻、事件或企业内部数据，它一无所知。
“幻觉”问题：当面对未知领域的问题时，模型可能会自信地编造事实（Hallucination），导致输出内容看似通顺但内容错误。

RAG 的核心理念非常简单：不要让大模型去“背”所有知识，而是给它配一个“图书馆”。

当用户提问时，RAG 系统不会直接让大模型生成答案，而是先执行两步操作：

检索（Retrieval）：在外部知识库中搜索与问题最相关的信息。
生成（Generation）：将检索到的信息连同用户的问题一起交给大模型，让模型基于这些事实生成最终回答。

一句话总结：RAG = 大模型（生成能力） + 外部知识库（事实来源）。

二、RAG 是如何工作的？（工作流 + 代码示例）

RAG 的工作流程通常包含以下四个关键步骤。下面我们通过一个具体的场景，用伪代码和逻辑图解来展示它是如何运行的。

🎯 场景设定

背景：一家科技公司的 AI 客服。
知识库（Vector DB）：包含《员工手册 2024 版》和《最新产品 Q3 发布说明书》。
用户提问：“我报销差旅费需要几个人审批？另外，Q3 发布的 AI 助手叫什么名字？”
问题难点：
- 审批人数在《员工手册》里，不在训练数据中。
- 产品名字是刚发布的，模型不知道。

🔧 步骤详解与代码逻辑

1. 数据准备与索引（Building the Library）

在系统上线前，我们需要将文档切片并转化为向量存入数据库。

# 伪代码：建立知识库
documents = [
 "《员工手册》：差旅费报销流程需经过直接主管和部门经理两级审批。",
 "《Q3 发布说明书》：我们于 2023 年 10 月发布了名为 'Nebula AI' 的智能助手。",
 "《Q3 发布说明书》：'Nebula AI' 支持自然语言处理和多模态交互。"
]

# 将文本分块 (Chunking)
chunks = split_text(documents)

# 将文本转化为向量 (Embedding) 并存入向量数据库 (如 Pinecone, Milvus)
for chunk in chunks:
 vector = embedding_model.encode(chunk)
 vector_db.upsert(id=chunk.id, vector=vector, metadata=chunk)

2. 用户提问（Query）

用户输入："我报销差旅费需要几个人审批？另外，Q3 发布的 AI 助手叫什么名字？"