RAG 工程里最大的痛點解決了，已開源

關于 RAG 這個話題，我之前寫過：

今天聊一個完全不一樣的角度——RAG / Agent context 工程里最大的痛點，從來不是 chunking 也不是 rerank，而是"數據陳舊"

你給 Agent 喂的代碼庫、會議紀要、Slack 記錄、文檔站，每天都在變。LangChain 那一套一次性建完索引就萬事大吉？做 demo 行，上生產你就知道有多痛——文件改一個，整個 vector DB 要不要重建？build 一次幾十分鐘？凌晨跑批結果第二天還是看到舊數據？

就是沖這個痛點來的，我今天介紹一個項目叫 CocoIndex

地址：github.com/cocoindex-io/cocoindex

它給自己的定位很狠："為 Agent 提供持續 fresh 的上下文"——不是搭一個 RAG 框架，是搭一個專門為 AI workload 設計的增量數據引擎

我看完它的設計哲學之后只有一個感覺：這才是 RAG / agent context 的正確打開方式

簡介

先放一句話定位：

? CocoIndex is an incremental engine for long-horizon agents.Turn codebases, meeting notes, inboxes, videos … into live context for your agents to reason over effectively — with minimal incremental processing. Fresh data anytime.

翻譯成大白話：把企業里的代碼庫、會議筆記、郵件、視頻、文檔全部接進來，統一變成 Agent 可查詢的實時上下文，只重處理變化的部分

它的核心心智模型只有一句話——target = F(source)

你聲明目標狀態，引擎負責讓目標狀態和源數據持續同步。源變了或者代碼（F）變了，引擎自動算出 delta 重跑。這套思路在前端工程師眼里非常熟悉——就是 React 在數據工程的版本

官方原話叫 "React for data engineering"，我覺得說得相當準確

核心特點：

• 增量優先（Incremental by default） ：每次只處理 delta，單文件改動 → 單行重 sync，不再有"凌晨重建索引"這種事

• 聲明式（Declarative） ：Python 寫轉換函數，引擎自動并行調度，沒有 DAG，沒有 YAML，沒有 Airflow 那一堆運維負擔

• 代碼改了也是 delta ：F 變了之后只重跑受影響的行，schema 自動演進， no index swap, no downtime ——這點我得給個 star，比 LangChain 那種"換個 embedding model 就重建一切"友好十倍

• 為長 horizon agent 設計 ：不是 demo 級框架，retry / back-off / dead letter / lineage / observability 全部內建，就是奔著生產去的

• Rust 內核 + Python 接口 ：性能層 Rust，業務層 Python，在 RAG 框架里屬于稀缺組合

CocoIndex 是 Python 包，pip 直接裝：

pip install -U cocoindex

按官方 quickstart，5 分鐘跑通一個 PDF → Markdown 的增量管道

先建個項目目錄、放點 PDF 進去：

mkdir cocoindex-quickstart && cd cocoindex-quickstart
mkdir pdf_files
echo "COCOINDEX_DB=./cocoindex.db" > .env
pip install -U cocoindex docling

寫一個 main.py，把 PDF 轉 Markdown 的邏輯聲明出來：

import pathlib
import cocoindex as coco
from cocoindex.connectors import localfs
from cocoindex.resources.file import PatternFilePathMatcher
from docling.document_converter import DocumentConverter

 _converter = DocumentConverter()

 @coco.fn(memo=True)
def process_file(file: localfs.File, outdir: pathlib.Path) -> None:
    markdown = _converter.convert(file.file_path.resolve()) \
        .document.export_to_markdown()
    outname = file.file_path.path.stem + ".md"
    localfs.declare_file(outdir / outname, markdown, create_parent_dirs=True)

 @coco.fn
asyncdef app_main(sourcedir: pathlib.Path, outdir: pathlib.Path) -> None:
    files = localfs.walk_dir(
        sourcedir,
        recursive=True,
        path_matcher=PatternFilePathMatcher(included_patterns=["**/*.pdf"]),
    )
    await coco.mount_each(process_file, files.items(), outdir)

 app = coco.App(
    "PdfToMarkdown",
    app_main,
    sourcedir=pathlib.Path("./pdf_files"),
    outdir=pathlib.Path("./out"),
)

跑起來：

cocoindex run main.py

第一次會處理所有 PDF，第二次再跑——只有新增或修改的 PDF 會被處理，其他的因為 @coco.fn(memo=True) 標記被自動跳過

注意幾個細節：

• @coco.fn(memo=True) ：標記這個函數的輸出可緩存，輸入指紋一致就直接復用結果

• localfs.declare_file() ：聲明一個 target 文件，源被刪了 target 也會自動跟著刪， 自動反向 GC

• coco.mount_each() ：每個文件自動掛一個獨立的處理組件，并行跑

整個心智模型就是寫一次性腳本——但引擎自動給你套上增量、緩存、并行、target sync 這一整套生產能力

進階案例：把播客做成知識圖譜

PDF → Markdown 太樸素了，看不出威力。CocoIndex 官方博客里有一個我特別喜歡的進階 demo——把 Lex Fridman、Dwarkesh Patel 的播客做成可查詢的知識圖譜

整體管線是這樣的：YouTube URL → yt-dlp 下載音頻 → AssemblyAI 帶說話人識別的轉錄 → LLM 抽取人物 / 技術 / 組織 / 論斷 → SurrealDB 存圖

下圖是整個管線的架構圖：

CocoIndex 播客知識圖譜管線

知識圖譜的 schema 設計了 5 種節點（session / statement / person / tech / org）和 4 種關系：

知識圖譜 schema

整個流程跑三個 phase：

Phase 1：每個 episode 獨立處理——下載、轉錄、LLM 抽實體和論斷。session 和 statement 立刻寫庫，因為不需要跨 episode 去重

Phase 2：跨 episode 收集所有人名 / 技術名 / 組織名，用 embedding 相似度 + LLM 二次確認做實體消歧（同一個 GPT-4 不同集里可能寫成 "GPT-4"、"GPT4"、"OpenAI's GPT-4"）

Phase 3：把消歧后的實體和關系寫庫

Phase 1 詳細流程

代碼骨架長這樣（取最關鍵的 fetch_transcript 一段）：

@coco.fn(memo=True)
asyncdef fetch_transcript(youtube_id: str) -> SessionTranscript:
    url = f"https://www.youtube.com/watch?v={youtube_id}"
    with tempfile.TemporaryDirectory() as tmpdir:
        audio_path = os.path.join(tmpdir, "audio.mp3")
        ydl_opts = {"format": "bestaudio/best", "outtmpl": audio_path,
                    "quiet": True,
                    "postprocessors": [{"key": "FFmpegExtractAudio",
                                        "preferredcodec": "mp3"}]}
        with yt_dlp.YoutubeDL(ydl_opts) as ydl:
            info = ydl.extract_info(url, download=True)
        config = aai.TranscriptionConfig(speaker_labels=True)
        transcript = aai.Transcriber().transcribe(audio_path, config)
    utterances = [Utterance(speaker=u.speaker, text=u.text)
                  for u in transcript.utterances]
    return SessionTranscript(utterances=utterances, ...)

注意那個 @coco.fn(memo=True)——同一個 YouTube ID 跑過一次之后永遠不會再下載第二次，哪怕你重啟進程、改了下游的 LLM prompt，轉錄這一步的結果直接復用

我看完這個 case 的最深感受：這就是為什么"data infra for AI"應該是一個獨立賽道

LangChain 那種"我封裝一遍 OpenAI、Pinecone、PDF loader 就叫框架"的玩法，跟 CocoIndex 這種從增量引擎、lineage、schema 演進、failure recovery 一層一層往下做的根基性工作，根本不是同一個量級

總結

老章對它的評價：這是目前我見過最像"工業級 RAG/agent context 基礎設施"的開源項目

優點：

• 心智模型極其干凈，target = F(source)，剩下交給引擎，寫起來跟一次性腳本沒差別

• 增量是 first-class citizen，不是"我們也支持增量"那種半吊子

• 代碼改動也算 delta，schema 自動演進，對長期維護的 RAG 系統來說太重要了——你換個 embedding model 不用全量重建

• Rust 內核保證了性能，長跑大規模數據的場景比純 Python 框架靠譜

• 內置 CocoInsight 控制平面，lineage / 緩存 / 版本 / 調度全可觀測，運維友好

• 文檔質量很高，每個 example 都是開箱即跑的工業級代碼，不是"hello world"水平

缺點 / 局限：

• 學習曲線比 LangChain 陡——你得理解"聲明式增量"這套思路，寫慣了命令式管道的人需要扭一下腦子

• 中文資料目前幾乎為零，社區問題主要在 Discord，英文交流

• target 端連接器現在主要覆蓋 vector DB / graph DB / data warehouse，傳統的全文檢索（ES / OpenSearch）支持還在補

• 團隊還小（一年從 1k stars 走過來），生態成熟度不如 LangChain / LlamaIndex 那種巨無霸

適合誰用：

• 在做 生產級 RAG 系統 的工程師，特別是數據每天都在變（codebase / Slack / 文檔站 / 郵件）的場景

• 在做 編碼 agent / code-review agent / security-audit agent ，需要隨時拿到最新代碼索引和 call graph

• 在做 知識圖譜 + LLM ，需要持續從多源數據里增量抽實體的

• 覺得 LangChain 一坨膠水代碼不夠"工程化"的人

不適合誰：

• 只做單次實驗、demo、一次性 batch 跑完就不管的場景——增量引擎對你是 overkill

• 完全不會寫 Python、希望 zero-code 拖拖拽拽的——這玩意兒還是面向開發者的

• 公司已經有重度 LangChain / LlamaIndex 投入、且數據規模不大的——遷移收益不一定值得

CocoIndex 團隊 2025 年 3 月開源，5 月 8 日 1k stars，到現在差不多一年時間，已經迭代到 v1，commit 節奏非常猛

他們 blog 里有篇文章叫 *"AI-Native Data Pipeline - Why We Made It"*，核心觀點我特別認同：

? 下一波 AI 應用真正的瓶頸不在模型，而在喂給模型的數據是不是新鮮、可信、可追溯

模型只能做它看到的數據所允許的判斷。如果你給 Agent 的代碼索引是上周的、文檔是上個月的、對話歷史是上次重建索引時的——再聰明的 Agent 也會一本正經地胡說八道

模型卷了三年，是時候卷一卷"喂給模型的數據"了——CocoIndex 這條路是對的

一句話總結：如果你正在認真做 RAG 或 Agent context，今晚就裝上玩玩，CocoIndex 大概率會改變你對"數據管道"這件事的理解

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！