不要等提问时才把知识临时拼起来，而是提前把资料编译成 Wiki——从向量检索走向知识大脑，中间隔着的正是这一步。
最近在给一个几千页的内部知识库做检索优化时，我又一次撞上了那个老问题：切 Chunk、算 Embedding、存向量库，这套标准 RAG 流程搭起来很快，但知识库一大，麻烦就跟着来了。
标准流程大家都熟：文档切块，生成向量，存进数据库，用户提问时召回几个片段丢给大模型生成答案。简单、成熟，能解决很多问题。但当文档从几十篇涨到几千几万页后，一些问题会慢慢浮出水面——文档之间到底什么关系？某个结论是从哪份资料来的？多篇资料互相矛盾时怎么办？知识库更新了，旧索引跟着变了吗？系统能不能从好几个页面里综合出一个完整答案，而不是简单拼几段文字？如果库里根本没有相关信息，它能不能老实说“不知道”，而不是硬编一个？
这些问题，光靠向量检索基本解决不了。
这段时间我在研究一个叫 GBrain 的项目，它代表的是另一种思路：不要等用户提问时才临时把知识拼起来，而是提前把原始资料整理、编译成一套结构化、可链接、可审计的知识 Wiki。这篇文章就是我从安装、建图、存储、Embedding、混合检索，一路折腾到 search 和 think 的实战记录，尽量把每一步都写到能动手验证的程度。
📌 本文看点
01
传统 RAG 卡在哪
02
Markdown 长出关系图
03
从 search 到 think
01
BOTTLENECK
传统 RAG 到底卡在哪
传统 RAG 的流程大致是这样：原始文档切分成 Chunk，生成 Embedding，写入向量数据库，用户提问，系统召回相关片段，交给大模型生成答案。
好处很明显：搭建快，不需要提前把文档全部读一遍理解透，对新增文档也友好，很适合快速拉起一套企业问答系统，后续还能通过换 Embedding 模型或者向量库继续优化。
但它有个天然的毛病：每次查询，系统都在重新找、重新拼、重新解释一遍知识。知识被拆成一堆孤立的 Chunk，机器检索起来没问题，但对人来说，这堆 Chunk 未必构成一套容易读、容易理解、容易维护的知识体系。
举个例子，知识库里可能有这么几篇文档：compiled-rag.md、gbrain.md、retrieval.md、compiled-rag-cost.md、benchmark.md，分别讲编译式 RAG 的概念、GBrain 的实现、检索机制、成本和评测结果。传统 RAG 能在提问时从这几篇里召回若干片段，但它不会主动告诉你：这几个页面其实是同一个主题下的不同侧面，哪个页面是对另一个的补充，哪些内容是定义、哪些是有争议的观点，哪些页面该放在一起读，哪些内容其实已经过时了。
02
PARADIGM
编译式 RAG 换了个思路
编译式 RAG 把知识处理这一步提前了：原始资料先经过知识编译，变成一份结构化的 Wiki，页面之间建立链接和关系图，再生成检索索引，用户提问时基于这套 Wiki 去查询和综合。
这里真正的变化，不是“把向量检索换成了知识图谱”，也不是“不需要 Embedding 了”，而是知识不再只是存在机器索引里的若干片段，而是先被整理成一份人和机器都能看懂的知识产物——用 Markdown 这种人类可读的格式写，页面之间有显式链接，可以进 Git 做版本管理，能用 git diff 看变化，能被人工修改审阅，也能被 Agent 继续编译维护，还能进一步生成数据库索引、向量和关系图。
Karpathy 之前提过 LLM Wiki 的思路，大意就是让大模型不再只是每次查询临时读一遍资料，而是像维护 Wiki 一样，把读过的内容沉淀成结构化知识。GBrain 算是把这个思路工程化了一步，做出了一套能真正跑起来的存储、建图、检索和综合能力，不光能解析 Markdown 里的 Wikilink，还能做跨页面综合和引用输出。
03
STRUCTURE
先搞清楚整体结构：容易混淆的“三层”
动手之前得先理清楚 GBrain 的结构，这里有两套“三层”很容易被搞混。
第一套：知识本身怎么组织
原始资料放在 raw/ 目录，知识产物放在 wiki/ 目录，另外还有一份规则文件负责编译约束。一个最小的知识库大概长这样：
．．．text
llm-wiki-demo/
├── raw/
│ ├── articles/
│ └── notes/
├── wiki/
│ ├── index.md
│ ├── concepts/
│ ├── people/
│ └── companies/
├── CLAUDE.md
└── log/
└── ingest-log.md
raw/ 保存的是原始资料——网页、会议纪要、项目文档、技术方案、代码仓库、人工笔记、数据库导出的内容，可以理解成知识系统的“源代码”，原则上不该被模型随意覆盖。wiki/ 保存的是整理好的知识页面，和普通文档比，它通常有稳定的命名、明确的主题、统一的结构、页面间的 Wikilink、类型标签、相关页面导航和来源时间戳。规则文件则告诉模型页面该怎么命名、不同类型的知识怎么组织、哪些关系要建链接、哪些内容要保留来源、哪些字段必填、什么时候能改旧页面——作用有点像编译器里的语法规则和类型约束。
第二套：GBrain 内部的能力分层
Graph 负责连接，把页面之间的关系组织起来，比如 Alice Chen 创办了 NexaFlow、任职于 Example Corp，NexaFlow 又投资了 SparkField；Storage 负责存储，管页面存哪、Chunk 怎么存、Embedding 怎么存、图谱边怎么存、用本地库还是远程库；Retrieval 负责检索，可能同时用到关键词检索、向量检索、全文检索、混合检索、重排和图关系扩展。
还有一对概念：source 与 brain
前者是知识从哪来，后者是知识怎么被系统使用。具体流程是 Git 里的 Markdown 经过编译和导入，变成数据库中的页面、Chunk、向量和关系。这里有句话值得记住：
「Git 里的 Markdown 是源真相，数据库里的内容是编译产物。」
跟编程语言里“源代码”和“可执行文件”的关系很像——你应该改源代码然后重新编译，而不是直接去改编译后的二进制文件。GBrain 也是这个逻辑：改 Markdown，重新执行 import 或同步，让数据库重新生成对应的派生数据。如果直接改数据库里的 Chunk，下次重新导入很可能就被源文件覆盖了。
04
INSTALL
安装这一步就能踩坑
正式开始前先确认装的是对的 GBrain。
！踩坑提示 🕳
千万别直接执行 npm install -g gbrain——npm 上这个包名早就被一个 GPU JavaScript 库占了，跟我们要用的项目没关系。装完如果看到版本号是 gbrain 1.3.1 这种，那基本就是装错了。真正要用的 GBrain 版本以仓库当前版本为准，本文用的是 0.42.x 系列。
也别图省事直接用 bun install -g github:garrytan/gbrain 这种全局安装方式，部分环境下 Bun 的全局安装会因为 postinstall 脚本的安全限制而失败。更稳妥的做法是下载源码，在源码目录里 bun install，再用 bun link 把 CLI 链接到全局路径：
．．．bash
git clone https://github.com/garrytan/gbrain.git
cd gbrain
bun install
bun link
然后跑 gbrain --version 确认输出是 0.42.x 系列。
为什么要死磕版本？因为这个项目迭代实在太快，不同小版本之间行为可能变——init 对 Embedding 的处理方式、配置字段名称、schema 检测命令的行为、某些命令的参数、本地库和远程库的支持范围都可能不一样。团队实践时至少该把 GBrain 版本、Bun 版本、Embedding 模型、向量维度、数据库引擎、LLM Provider 这几项记下来，免得出现“我这能跑，换台机器就全乱了”的情况。
05
SELF-WIRING
第一步：让 Markdown 自动长出关系图
装完先别急着配 Embedding，我们先只做一件事：把 Markdown 页面之间已经写好的链接，转成一张可查询的关系图。
准备几篇带 Wikilink 的 Markdown，比如：
．．．markdown
编译式 RAG 是一种知识组织范式。
它与 [[gbrain]] 有直接关系，
同时也涉及 [[compiled-rag-cost]] 中讨论的成本问题。
这里的 [[gbrain]] 和 [[compiled-rag-cost]] 就是页面间的显式链接。
GBrain 把这个自动接线的过程叫 self-wiring：扫描 Markdown 里的 Wikilink，把链接转换成图谱里的边。比如 Alice founded [[companies/nexaflow]] 会得到 alice-chen ── founded ──＞ nexaflow 这样一条边；如果上下文里没有明确的关系动词，就退化成一条 mentions 边。常见关系类型包括 founded（创办）、works_at（任职）、invested_in（投资）、advises（顾问）、mentions（提及） 这几种。
self-wiring 之所以不用调 LLM，是因为它处理的不是让模型从一大段散文里猜实体关系，而是已经写好的显式链接——目标页面是作者明确写出来的，关系类型能靠链接周围的确定性规则识别。这样一来成本低、结果可复现、规则明确、方便调试，还能追踪来源上下文。这跟 GraphRAG 是两码事：GraphRAG 通常要从没有显式结构的自然语言里抽实体和关系，self-wiring 面对的则是已经有 Wikilink 结构的 Markdown，二者处理的是不同类型的输入，谈不上谁替代谁。
典型流程是先初始化一个不带 Embedding 的库：
．．．bash
gbrain init --pglite --no-embedding
gbrain import ./wiki --no-embed
gbrain extract links --source fs --dir ./wiki
–no-embedding 和 --no-embed 的意思是先不算向量，只把页面、Chunk 和关系导入数据库。跑完用 gbrain stats 看结果，重点看 Pages、Chunks、Embedded、Links 这几个数字。比如输出是 Pages 5、Chunks 8、Embedded 0、Links 6，说明 5 个页面入库了，切出 8 个 Chunk，还没算 Embedding，建了 6 条关系边。
想看某个页面具体连了什么，用 gbrain graph compiled-rag，能看到当前页面连到了哪些页面、关系类型和方向。反向链接用 gbrain backlinks gbrain，回答的是“哪些页面引用了当前页面”这个问题。如果输出带上下文信息，还能进一步追溯这条边来自哪个页面、原始链接写在什么位置附近、为什么会被识别成这种关系——这也是 self-wiring 比较有价值的地方：它不只是生成关系，还把关系的来源上下文一并保留了下来。
06
STORAGE
有了 Markdown，为什么还要数据库
看到这里很多人会问：知识已经存在 Markdown 里了，为什么还要导入数据库？
答案是两者解决的是不同问题。Markdown 容易读、容易改，方便 Git 管理、看 diff、回滚历史，也方便人工审阅，不依赖特定数据库，更适合当知识的源真相。数据库负责保存页面元数据、切分后的 Chunk、Embedding、图谱关系，执行关键词检索和向量检索，保存运行时状态，支持结构化查询。整体关系是 Markdown 经过解析、切分、建图、向量化之后变成数据库——数据库不是 Markdown 的替代品，而是它的运行时编译产物。
改了源文件会自动同步吗？不会。假设 compiled-rag.md 已经导入过数据库，之后你在文件末尾加了一段内容——Git 里的 Markdown 变了，但数据库里的旧 Chunk 和旧 Embedding 不会自动跟着变，查询结果可能还是基于旧内容。必须重新执行 gbrain import ./wiki 或者对应版本支持的同步命令。这是编译式系统绕不开的问题：源文件变了，不代表编译产物也跟着更新了。
实践中可以靠对比 Git 提交时间和数据库里的 updated_at、记录每次导入日志、给知识库建增量同步任务、对重要页面在改动后跑一遍回归查询，来判断数据库是不是过期了。
07
ENGINE
PGLite 还是 Postgres
GBrain 支持不同的数据库引擎，最常见的是 PGLite 和 PostgreSQL 这两个。
PGLite 可以理解成运行在进程内部的嵌入式 PostgreSQL，把 PostgreSQL 编译成了 WebAssembly，不用单独起一个数据库服务。好处是不用装数据库服务、不用配端口、不用管账号，数据存在本地目录就行，很适合个人知识库和本地实验，用来快速验证整个流程也很方便：
．．．bash
gbrain init \
–pglite \
–path ./output/brain-l2 \
–embedding-model dashscope:text-embedding-v3 \
–embedding-dimensions 1024 \
–non-interactive
–pglite 用本地嵌入式数据库，–path 指定数据库目录，–embedding-model 和 --embedding-dimensions 指定向量模型和维度，–non-interactive 适合脚本自动化。
！踩坑提示 🕳
Embedding 模型的维度必须和数据库配置一致，模型输出 1024 维，数据库按 1536 维建的，初始化或写入的时候就可能撞维度冲突。
但 PGLite 好用不代表它适合所有场景。它是进程内运行的，不监听普通数据库端口，不能直接用外部 psql 连，有单写者约束，不适合多个独立进程同时写，后台 worker 能力也有限——更适合个人知识库、本地调试、实验环境和单机工具。
如果需要多人共享、多服务访问、多进程并发、后台任务、远程访问、统一权限管理，或者要上生产，那就该用独立的 PostgreSQL，向量检索还得启用 pgvector 扩展。本地 Docker 可以用带 pgvector 的镜像：
．．．bash
docker run -d \
–name gbrain-pg \
-e POSTGRES_PASSWORD=postgres \
-p 5432:5432 \
-v ~/Docker/gbrain-pg-data:/var/lib/postgresql/data \
pgvector/pgvector:pg17
然后 gbrain init --url “postgresql://postgres:postgres@localhost:5432/postgres” 连上去。注意别把普通 postgres 镜像和带 pgvector 的镜像搞混，普通镜像不一定预装了向量扩展。
之所以两个引擎能共用一套命令，是因为 GBrain 内部有一层统一的引擎抽象，上层命令只管导入、查询、搜索、建图、向量化、统计、综合这些事，底层用 PGLite 还是 Postgres 由引擎实现去处理。理想情况下，本地 PGLite 验证完流程，迁移到 Postgres 时上层命令基本不用改。
简单归纳一下选型：个人本地实验和单机知识库用 PGLite；团队共享、多进程写入、后台 worker、生产部署、需要远程连接的场景用 Postgres。
08
EMBEDDING
开启 Embedding：给知识加上语义坐标
前面的建图实验一直用 --no-embedding，系统能保存页面、切分 Chunk、建关系、查图谱，但还做不了真正的语义检索。
Embedding 说白了就是把一段文本转成一组数字，比如“为什么编译式 RAG 需要提前整理知识？”会变成一个可能有上千维的向量。语义相近的文本，在向量空间里的位置通常也更接近，所以查询时把用户问题也转成向量，再去数据库里找距离近的内容就行了。
图谱和 Embedding 解决的是不同问题：图谱回答“页面之间有什么关系”，Embedding 回答“哪些内容在语义上跟当前问题相近”。“Alice founded NexaFlow” 这句话，图谱能表达成一条 founded 边，但 Embedding 更擅长回答“谁创办了 NexaFlow？”这类问题——即使用户没用原文里的句式，也可能靠语义相似度召回相关页面。
假设准备了一批人物和公司页面：
．．．text
gbrain-wikilink-data/
├── people/
│ ├── alice-chen.md
│ ├── bob-morgan.md
│ └── carol-wu.md
└── companies/
├── alphaventures.md
├── nexaflow.md
└── sparkfield.md
这次导入不加 --no-embed：gbrain import ./gbrain-wikilink-data/，系统会依次扫描 Markdown、切 Chunk、调 Embedding API、生成向量、写入数据库。导完用 gbrain list -n 10 看看，再跑 gbrain doctor 检查健康状态，重点看 Embedding 相关指标，如果所有页面都成功生成了向量，Storage 层就算具备语义检索的基础了。
配置 Embedding 时几个常见问题：
1
维度不一致：比如数据库配了 1536 维，模型实际输出 1024 维，初始化或导入就可能失败。
2
Embedding 其实没真正开启：某些版本的历史配置里可能留着 “embedding_disabled”: true，就算本次命令传了 Embedding 模型，也可能因为旧配置没生效，排查时得看配置文件而不是只看命令行参数。
3
API Key 和服务端点不匹配：比如用国内区域申请的 Key 却把请求发到国际端点，报出来的 invalid_api_key 不一定是 Key 本身的问题，也可能是地址不对。
遇到这类错误建议一并检查 API Key、Provider、Base URL、模型名称、区域配置和网络连通性。
09
HYBRID
混合检索为什么值得做
有了 Embedding 之后能做向量检索了，但只靠它未必是最优解——语义相似和关键词精确匹配解决的是两类不同的问题。
关键词检索 适合人名、产品名、API 名称、错误信息、文件名、版本号这类特定术语，比如查 “PGLite”，关键词检索更容易精准命中。向量检索 适合同义表达、模糊问题、用户没用原文关键词的自然语言描述，比如用户问“为什么知识库需要提前整理？”，相关页面写的可能是“知识编译”“查询前构建 Wiki”“结构化知识产物”这些词，字面上不重合，但语义高度相关。
混合检索的基本思路是用户问题同时走关键词检索和向量检索两条路，再把结果融合、去重、排序后返回——关键词负责精确性，向量负责语义覆盖，两条路结合能减少单一路径的盲点。
实现层面常涉及 BM25、向量相似度、HNSW 和 RRF 这几个东西。BM25 接近关键词相关性打分，向量检索靠距离或相似度判断语义相关性，问题是 BM25 分数和向量相似度未必在同一个量纲上，直接相加很容易让某一路天然占主导。
所以混合检索常用 RRF（Reciprocal Rank Fusion），它不直接比两路的分数，而是比排名——关键词检索排第 1、向量检索排第 3，综合起来会得到比较高的权重，核心思路是不纠结不同算法的绝对分数，让不同检索路径按排名投票。
想实际比较三种检索方式，可以拿同一个问题“编译式 RAG 为什么需要预先整理知识？”分别跑 keyword、vector、hybrid 三种模式，观察 keyword 是否命中了准确术语、vector 是否找到了语义相关的页面、hybrid 是否兼顾了精确性和覆盖范围。别只看返回了几条结果，还得看第一条是不是真相关、前五条里有几条有用、有没有漏掉关键页面、有没有大量重复、有没有把相似但无关的内容排前面、延迟能不能接受。
10
SYNTHESIS
从 search 到 think，真正的跨越在哪
这是整个系统最值得说道的部分。
search 干的事是找到相关页面并返回。用户问“编译式 RAG 与传统 RAG 有什么区别？”，系统可能返回 compiled-rag.md、gbrain.md、compiled-rag-cost.md、retrieval.md 这几篇。这已经比没有检索强不少，但用户还得自己打开这些页面、读内容、对比观点、识别重复信息、判断哪些能组合、找证据、写结论——search 给的是一份页面列表。
think 往前多走了一步，做跨页面综合。流程是先检索相关页面，扩展相关关系，读取多个页面，提炼证据，跨页面综合，生成答案，最后附带引用和知识缺口。它跟 search 的差别不是“多返回几篇文档”这么简单，真正增加的是跨页面阅读、证据整合、关系扩展、观点比较、结构化回答、引用生成和知识缺口识别这几项能力。
举个例子，“为什么编译式 RAG 的查询成本可能更高，但仍然值得使用？”这个问题不太可能靠一篇页面回答完，可能得同时读编译式 RAG 的定义、传统 RAG 的工作方式、多页面综合机制、检索页面数量、Token 消耗、评测结果、适用场景分析这几块内容，最后组织成一条完整的论证链：因为要读取和综合更多页面所以更贵，但换来了更强的跨源综合与可追溯能力，值不值得用取决于任务复杂度和知识库稳不稳定。这跟简单返回几个 Chunk 有明显区别。
「引用不是装饰，是证据链。」
一个好的综合答案应该能回答：这个结论从哪来、哪个页面支持哪句话、这句话是原文事实还是综合推断、结论有问题该回哪核查。理想的输出结构是一条结论配上几条具体来源，比如证据 1 来自 compiled-rag.md、证据 2 来自 retrieval.md，这样答案不只是“看起来合理”，还能追溯。
更重要的是，一个成熟的知识系统不该为了给出完整答案就编造信息。它应该能老实告诉用户：当前知识库没有相关资料、只有一个来源支持这个结论、不同页面之间有冲突、某个结论缺时间信息、某个页面可能已经过期、需要补充新的原始资料。think 的价值不只是帮你回答，还包括告诉你知识库现在还缺什么。
11
MAINTAIN
知识库不是导一次就完事了
知识库真正跑起来之后，工作才刚开始。现实中的资料会持续变——新文档不断加进来，老文档要修订，页面链接可能失效，关系类型可能写得不统一，旧 Embedding 得重新算，有些内容可能过时了，不同来源之间可能打架。
基本的维护流程是：新增原始资料导入 raw/，编译或更新 Wiki，补充 Wikilink，重新建图，更新 Chunk 和 Embedding，跑一遍回归查询确认没坏。
至少要盯着这几类问题：
1
断开的链接：页面引用了不存在的目标页。
2
孤立页面：存在但没被任何页面引用也进不了导航。
3
重复实体：同一个人被写成 alice-chen、alice、alice_chen 三种形式，图谱里就会出现重复节点。
4
关系类型不统一：同一种关系一会儿写 works_at 一会儿写 work_at 一会儿写 employed_by，后续查询统计会很麻烦。
5
内容过期：页面还在，但里面的版本、配置或结论已经失效了。
6
来源缺失：页面有结论却没记录它是从哪份原始资料来的。
维护体系里 Skill 和 MCP 经常一起出现，但解决的问题不一样——Skill 规定“应该怎么做事”，MCP 提供“可以调用什么能力”。比如一个知识库维护 Skill 可以规定读取新增资料后要更新对应 Wiki 页面、补充链接、检查断链、更新索引、跑评测；MCP 则负责连接文件系统、数据库、搜索服务、外部 API、远程知识库、工单系统这些外部能力。简单说，Skill 更像操作流程，MCP 更像能力接口。
12
EVALUATE
怎么判断知识大脑真的变好了
一个 Demo 能回答问题，不代表它已经是个可靠的系统，至少得从四个方面评估。
检索质量 看相关页面能不能被召回、关键页面排不排得到前面、有没有大量无关结果、混合检索是不是真的比单一路径强。综合质量 看是不是正确理解了多个页面、有没有遗漏关键条件、有没有把不同来源的内容混在一起、有没有错误推断页面间的关系。引用质量 看每个关键结论有没有来源、引用是不是真的支持对应结论、有没有把推断说成事实、能不能定位到原始页面。成本和延迟 看单次查询的 Token 消耗、平均响应时间、实际读取的页面数、Embedding 调用次数、LLM 综合次数、数据库检索耗时。
评测数字也不能随便拿来比。数据集是什么、测试问题是什么、用了什么检索模式、是否公开可复现、是不是模型自动评分、有没有用厂商自建数据、指标具体代表什么，这些都得先搞清楚。比如 LongMemEval 和 BrainBench 不能简单放一张表里直接比，二者的任务、数据、评价方式和实验条件都不一样，即便都是百分比，也未必在同一个坐标系里。引用评测数字时至少要交代清楚数据集、测试版本、检索模式、评测指标、数据来源和是否可复现这几项。
成本高不等于质量差。编译式 RAG 可能要检索更多页面、读更多上下文、做跨页面综合、生成更详细的引用、分析知识缺口，查询成本大概率比只召回几个 Chunk 的向量 RAG 高，但这不意味着它更差，两者其实是在拿不同的东西做交换：
| 维度 | 传统向量 RAG | 编译式 RAG |
|---|---|---|
| 查询成本 | 通常更低 | 可能更高 |
| 知识可读性 | 依赖原始文档 | Wiki 产物更清晰 |
| 页面关系 | 通常较弱 | 可以显式建图 |
| 跨页综合 | 需要额外实现 | 可以作为核心能力 |
| 审计与 diff | 取决于系统设计 | Markdown 天然友好 |
| 高频变化资料 | 更灵活 | 需要持续编译 |
| 稳定知识库 | 适合 | 更能体现价值 |
「真正该问的问题从来不是“哪种 RAG 永远更好”，而是“我的知识库稳不稳定、任务需不需要深度综合、我愿不愿意承担知识编译和维护的成本”。」
13
ROADMAP
从零开始的实践路线
如果打算自己动手搭一遍，大致可以按这个顺序来。
阶段 01只做 Wiki 和建图
创建 Markdown 页面，用 Wikilink 互相连接，导入页面，建立关系，查看图谱和反向链接，得到一份可读的 Wiki 加一张可查询的关系图。
阶段 02补齐 Storage
初始化 PGLite，导入页面，查看 Chunk，理清源文件和数据库的关系，验证重新导入机制。
阶段 03开启 Embedding
配置模型，指定正确的向量维度，导入带向量的页面，用 doctor 和 stats 验证结果。
阶段 04比较不同检索方式
分别测试关键词、向量、混合检索，比较召回结果，记录延迟和命中情况。
阶段 05跑 search 和 think
用同一个问题对照，看 search 返回哪些页面、think 怎么综合多页、引用准不准、有没有输出知识缺口。
阶段 06建立维护和评测流程
持续加新资料、更新 Wiki、检查断链和孤儿页、跑回归问题集、统计成本和质量的变化。
∞
THE END
编译式 RAG 不只是多写点 Markdown
如果把编译式 RAG 简单理解成“提前生成一些 Markdown”，那多半是低估了它的价值——它真正改变的是知识库的工程方式。
传统 RAG 更关心文档怎么切、向量怎么生成、结果怎么召回、模型怎么回答；编译式 RAG 进一步关心原始资料怎么保存、知识怎么被整理、页面之间怎么建关系、规则怎么约束编译过程、内容怎么持续更新、结论怎么带上证据、知识缺口怎么被发现、系统怎么靠评测不断改进。说到底，传统 RAG 更像是在资料堆里找答案，编译式 RAG 则是先把资料整理成一套知识系统，再从这套系统里回答问题。
GBrain 的价值也不只是多了一个 CLI 工具，而是把这套思路落到了几个能实际操作的环节上：Markdown 经过知识编译和 self-wiring 自动建图，存进数据库，算好 Embedding，跑混合检索，配合 search 和 think，最终产出带引用的答案和知识缺口。
「知识库的目标从来不该只是“能回答问题”，而是知识可读、关系可查、来源可追溯、内容可维护、效果可评测。」
并且能随着资料积累持续变得更有价值。这才是从一个文档检索工具，走向知识大脑真正要跨过的那一步。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
