fojin
聚合全球613个数据源的佛教数字文献平台,基于RAG实现可溯源AI问答
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
聚合全球613个数据源的佛教数字文献平台,基于RAG实现可溯源AI问答
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
深夜,你对着一段《心经》陷入沉思——"色即是空,空即是色"究竟是什么意思?你打开搜索引擎,翻了十几篇解读文章,越看越困惑:有的说是缘起性空,有的说是破除我执法执,有的说是一种认识论……每篇文章都有道理,但你无法判断哪个更接近原意。
现在,假设你有这样一个工具:在搜索框里输入"色即是空,空即是色是什么意思",几秒钟后,它返回的不是博客解读,而是一段来自《心经》原文的引用,旁边标注了玄奘译本与梵文原文的对照,并附上注释书里历代法师的注解段落——每一句话都能溯源到原始文献,而不是某个人基于二手材料的个人理解。
这正是 FoJin(佛津) 正在做的事。
FoJin 是一个基于 AI 的佛教数字文献平台,中文名"佛津"取自佛教典籍《出三藏记集》,意为"佛典之津梁"——佛陀言教的汇聚与流通之地。项目由独立开发者 xr843 发起,目前 GitHub 收获 319 Stars,聚合了来自 CBETA(中华电子佛典协会)、SuttaCentral、84000.co、泰国法宗派佛教数字图书馆等 613 个数据源 的经文资源。
这个项目解决的核心痛点非常具体:佛教文献极度分散。据项目文档描述,相关资源散布在 CBETA、SuttaCentral、BDRC、SAT、84000、GRETIL 等数十个数据库中,每个数据库有各自的界面设计、数据格式和检索逻辑。用户想要完整理解某部经文,往往要在多个网站之间反复切换、复制粘贴。FoJin 的目标是把这些全部聚合到一个平台里,用 AI 把它们串联起来。
目前平台收录了 10,500+ 部经文,涵盖汉文、巴利文、藏文、梵文等多种语言,合计 23,500+ 卷的全文内容。项目自称是"首个由 LLM 驱动的三语跨藏平行对读平台",即通过 LLM 对 CBETA、SuttaCentral、84000 三个主要语料库进行段落级对齐,让用户可以在同一屏幕上对照阅读不同语言的同一段落。

图1:FoJin 平台首页,聚合了全球主要佛教数字文献库
FoJin 最核心的功能是 AI 问答,内部称之为"XiaoJin"(小津)。用户用自然语言提问,系统基于 680K+ 段落向量库进行 RAG(检索增强生成)检索,结合可选的 cross-encoder 重排和根经文召回,生成带有可点击引用的回答。每个回答都附带【《经名》卷N】格式的引用标记,点击后直接跳转到原始经文段落。
具体来说,问答链路经过这样几个环节:
平台的另一个特色功能是 15 位历史佛教大师人格问答:用户可以选择以某位法师(如玄奘、鸠摩罗什、慧远等)的"口吻"提问,系统将检索范围限定在该法师相关传统的经文中。每个人格背后对应一套独立的经文检索范围和 prompt 模板。
除问答外,平台还提供全文检索(基于 Elasticsearch 8)、三语跨藏平行对读(汉/巴利/藏文段落级对齐)、知识图谱(11 万+ 实体,基于 Deck.GL 的地理可视化地图)、32 部辞典 74.8 万+ 条目搜索等辅助功能。

图2:FoJin 全文检索界面,基于 Elasticsearch 提供多语言语义检索
从代码结构看,FoJin 是一个前后端分离的单体仓库(monorepo),技术栈清晰:
后端(Python,约 6.4 万行):
前端(React 18 + TypeScript + Vite):
部署架构(全部 Docker Compose 编排):
postgres(pgvector,向量库,内存限制 3GB)elasticsearch(全文索引,内存 1.5GB)redis(缓存/限流)backend(FastAPI 服务,Python 3.12 多阶段构建镜像)frontend(Vite 构建的 React SPA)umami(可选,网站统计分析)后端提供 30+ 个 API 路由模块,涵盖聊天检索、用户认证、数据管理、标注、知识图谱、辞典等核心业务。按架构文档的说法:"30 个模块都是同一套分层套路的复制"——即 API 路由 → Service 业务层 → 三套存储(PG/ES/Redis)的标准模式。
好消息是:项目提供了完整的 docker-compose.yml,在有 Docker 环境的机器上,运行 ./deploy.sh 或 docker compose up -d 即可拉起全部服务。生产环境还有专用的 deploy.sh 脚本,支持路径感知的增量部署——只 rebuild/reload 真正变动的服务,不做全量构建。
需要注意的:
docker-compose.yml 中分别配置了 3GB 和 1.5GB 内存限制,最低可用配置需要 8GB+ RAM。./elasticsearch/Dockerfile)。整体部署难度评定为 中等,有 Docker 经验的开发者 30 分钟内可完成部署。
数据来源依赖:平台的问答质量高度依赖底层文献数据库的覆盖度。CBETA 主要覆盖汉文大乘佛教经典,巴利文和藏文资源相对有限。如果用户研究的是其他传统的文献,可能检索不到足够的相关段落。
LLM 幻觉风险:虽然有 citation guard(引用守卫)模块做防幻觉检查,但 RAG 系统本质上还是"由 LLM 综合多段检索结果生成答案",幻觉风险无法完全消除。项目有配套的回归测试脚本(fojin-eval-regression.sh)做检索质量评测,说明团队对这个问题有意识,但评测覆盖度和实时性仍是挑战。
维护门槛:这是一个个人维护的项目,后端代码 6.4 万行,涉及 NLP/RAG/知识图谱/多语言处理等多个细分领域,单人维护的可持续性存疑。GitHub 上有 13 个 open issues,需要关注长期维护状态。
商业化风险:核心 LLM 调用依赖 OpenAI API,在大规模用户场景下成本不可忽视。项目目前没有公开明确的商业模式或 API 定价策略。
FoJin 的出现反映了一个更大的趋势:专业垂直领域(domain-specific)的 RAG 应用正在崛起。通用搜索引擎无法理解"《大般若经》卷四十七'清净'一词在唯识学中的特殊含义",但 FoJin 可以在 CBETA 的 23,500 卷经文中精准检索并提供引用。
佛教文献的特殊性在于:经典本身是核心资源,注释比原文更容易获取,但质量参差不齐。FoJin 通过根经文召回(root-sutra recall)机制,强制 LLM 优先引用原始经文而非二手注释,这是对通用 RAG 系统的针对性改进。
从技术角度看,项目整合了向量检索(pgvector ANN)、全文检索(Elasticsearch)、知识图谱(自定义实体关系)、OCR/解析(附件解析器)等多种检索范式,是一个复合检索系统的工程实践,对于研究多模态/多源检索融合的开发者有参考价值。
| 维度 | 评分 |
|---|---|
| 技术创新 | ★★★★☆(复合检索架构实用性强) |
| 数据规模 | ★★★★★(613源、10,500+经文,无出其右) |
| 工程完整度 | ★★★★★(文档、测试、部署脚本齐全) |
| 部署友好度 | ★★★★☆(Docker 一键部署但硬件要求高) |
| 长期维护 | ★★★☆☆(单人维护,活跃度尚可) |
一句话评价:FoJin 是佛教数字人文领域的"arXiv + Perplexity",用 RAG 技术把散落全球的经文文献变成了可提问、可溯源、可对照的知识平台,技术架构扎实,数据规模令人印象深刻,是数字佛学领域的标杆开源项目。