企业官网建设流程全解析

有时候做 RAG 项目，最让人头疼的不是模型选型，也不是向量库怎么调，而是第一步——数据根本进不来。尤其当你的资料库里躺着大量 PDF 和图片时，整个落地的节奏直接卡在解析环节。这篇是“RAG 数据导入与解析全攻略”的第二篇，专门聊图文与 PDF 解析：OCR 怎么做、多模态大模型要不要上、几十种工具到底选哪个。我把自己在真实项目里踩过的坑、验证过的思路、以及九种主流 PDF 工具的实测感受整理成文，给正在搭 RAG 知识库的朋友一份可以直接抄作业的参考。

先说结论：文本型 PDF 与扫描型 PDF 的解析路径完全不同，图片知识库也不是“能不能存”的问题，而是“以什么形式进入索引”的问题。下面我会从原理到实操逐步拆解，保证你看完能直接上手。

1. 为什么 PDF 和图片是 RAG 落地最先遇到的硬骨头

很多团队把 RAG 想得太简单，以为丢给大模型一个 API 就能自动处理所有文档。实际上，RAG 的检索质量完全取决于“索引里存了什么”——你导入的是干净文本，检索结果大概率靠谱；导入的是乱码和缺失内容，后面调什么都白费。PDF 和图片恰恰是脏数据重灾区。

1.1 知识库到底能不能存图片

先回答一个被反复问的问题：“RAG 知识库能存储图片吗？”直接说结论：传统向量数据库主要存文本 embedding，图片本身不能直接作为知识片段被检索。但你完全可以通过两条路径让“图片知识”生效：

• 把图片转成文字描述（OCR 或多模态模型），再按文本入库。这是目前 90% 以上项目的做法，简单可控，检索链路不用改。
• 把图片通过视觉模型编码成视觉向量，再与文本向量做多模态对齐。这条路线适合产品里需要“以图搜图”“图文混合检索”的场景，但工程复杂度高，对向量数据库也有额外要求。

所以“能不能存”背后其实是“要不要为图片单独建一套视觉索引”。如果你只是希望合同中的盖章页、设计稿里的文案能被搜到，方案一完全够用；如果你做的是素材管理类知识库，方案二才值得考虑。

1.2 文本型 PDF 与扫描型 PDF 的本质差异

PDF 这玩意儿有个迷惑性很强的地方：肉眼看起来一模一样的两页纸，底层结构可能完全不同。文本型 PDF，英文叫做 born-digital PDF，是 Word、LaTeX 这类工具直接导出的，页面内嵌了真实的文本对象，用解析器 can 直接把文字抠出来。

扫描型 PDF 本质是一组图片，常见于老档案扫描件、传真件、某些扫描仪直出的文件。这类 PDF 没有任何文字层，必须经过 OCR（光学字符识别）才能把图像里的文字变成可检索的文本。更麻烦的还有“混合型 PDF”——比如带电子签名的合同，首页是扫描图，后续页是文本，解析时需要逐页判断类型。

我在项目里见过最坑的场景：财务系统导出的 PDF 看起来排版工整，每行金额都能“复制”，用 pdfplumber 提取后文本顺序全乱，数据项和数值对不上。这种问题跟文本型还是扫描型无关，纯粹是版面结构的解析复杂度问题，后面工具选型章节会详细说。

1.3 解析做不好，检索与生成全是无源之水

很多人容易忽略解析和 RAG 上游的联动。假设你的 PDF 是扫描件，不做 OCR 直接入库，索引里全是空文本，用户问什么都检索不到；假设 OCR 出来的文字自带大量错别字，embedding 的效果会明显下降，因为错字会严重干扰语义向量的计算。

这里插一句我踩过的坑：有段时间我们把扫描合同用低质量的 OCR 快速过了一遍，结果用户检索“违约金比例”，索引里存的却是“违约金比侧”之类的错误文本，top-k 结果里永远召回不到正确片段。后来我们不得不重新清洗这批数据，成本比一开始认真做解析高了一倍都不止。

所以我的建议一直是：解析环节宁可慢一点、稳一点，也不要图快。数据一旦“带病入库”，污染的是整个知识库的检索质量，后期修正代价极高。

2. OCR 选型：从开源到云服务的完整路径

OCR 是图文解析的底座。选好了，图片和扫描件处理得干干净净；选不好，后面全是事。下面结合开源、商用两条路线，直接给可落地的选型建议。

2.1 三个开源 OCR 的实际体验对比

开源 OCR 里，目前最常被拿来比较的是 Tesseract、PaddleOCR 和 RapidOCR。

Tesseract 是老牌选手，由 HP 实验室开发，后来交给 Google 维护。它最大的优势是语言包丰富，全球主流语种几乎都有对应的训练数据。但实话说，对中文、表格、以及拍摄质量差的图片，Tesseract 默认模型的表现比较一般，需要自己调参甚至微调，不太适合零基础快速上手。

PaddleOCR 是百度开源的工具包，也是我目前最推荐优先尝试的。它对中文场景做了重点优化，识别准确率、版面分析、表格识别能力都很能打。尤其 PaddleOCR 3.0 发布后，支持了端到端的版面识别和表格还原，很多场景可以直接替代商业 OCR。我当时用默认参数跑一批手机拍的白板照片，文字识别效果比我预想的好很多，连续文本还原度都在 95% 以上。

RapidOCR 则是 PaddleOCR 模型的一种轻量化封装，部署起来非常轻便，通过 ONNX Runtime 运行，不需要安装 Paddle 全家桶。它的模型效果和 PaddleOCR 差不远，特别适合对部署体积敏感、或者需要在低配服务器上跑 OCR 的场景。

一句话总结：中文为主的项目，优先 PaddleOCR 或 RapidOCR；需要识别多语种，Tesseract 值得保留做备选。

2.2 云厂商 OCR 什么场景下值得付费

开源工具实力再强，遇到某些场景还是建议换商用 API。我总结的三类场景最值得付费：

• 复杂表格结构：合同、报关单、票据里的多级表头、合并单元格，开源的表格识别往往还原不彻底。云厂商大多推出了票据识别、表格还原专用接口，准确率肉眼可见高一个档次。
• 手写体与低质量影像：会议笔录、传真件、老照片里的手写文字，开源 OCR 基本崩盘，商用模型因为有大量真实业务数据训练，效果反而还行。
• 长文档批量处理：几万页合同，需要并行处理时，云 OCR 的异步任务接口比本地挨页跑快得多，而且省运维。

我见过比较典型的例子：用 PaddleOCR 线上识别增值税发票，关键字段（发票号、金额、日期）的抽取经常漏字段；换成云厂商的发票专用接口后，准确率直接从 80% 提到 99% 以上。这种差距主要来自专用模型的领域训练，开源通用模型很难覆盖。

安全提醒一句：合同、医疗记录这类敏感数据，使用云 OCR 前要仔细评估数据出境和合规要求。涉及隐私的内容，老老实实上本地开源方案更稳妥。

2.3 OCR 万能吗？先说清楚它的边界

OCR 的边界，很多人要吃一次亏才理解。我吃过，所以直接摆出来：

• OCR 只负责把图像里的文字变成字符序列，它不理解版面逻辑。双栏论文、报刊、图文混排，识别出来可能是乱七八糟的线性流水账。
• OCR 的准确率跟图片质量强相关。分辨率 200 DPI 以下、模糊、倾斜、反光，都会导致识别结果退化。不是工具不行，而是输入质量不够。
• OCR 的结果错字率不可能为零。尤其是古籍、特殊字体、生僻字，人工校对成本仍然存在。

所以，我的建议是：“OCR + 后处理”是一条完整链路。OCR 之后至少要做一遍文本清洗：去除非正文的页眉页脚、还原段落顺序、修正明显错别字，有需要的时候再用正则或规则抽取结构化字段。OCR 只是第一步，不是全部。

3. 多模态大模型：让 RAG 真正“看懂”图文

最近两年多模态大模型进展非常快，许多原本让人头疼的图文解析问题有了新的解法。GPT-4o、Qwen-VL、MiniCPM-V 这些模型，不仅能看图识字，还能理解图表逻辑、图片里的复杂关系。这让“图文进 RAG”的方式发生了一次重要升级。

3.1 多模态模型在图文解析里的三种用法

第一，当作超强 OCR 用。给模型一张图片，直接让它输出全部文字内容。相比传统 OCR，多模态模型对倾斜、模糊、复杂背景的鲁棒性更强，“自来水水表上的读数”这类场景也能处理。

第二，当作结构化抽取器用。随便拍一张名片，告诉模型“输出姓名、电话、公司、职位”，它能直接按 JSON 格式给你结果。做合同关键字段抽取时，这种用法比“OCR + 正则”省太多事。

第三，当作图片内容生成器用。把图表、流程图、产品截图直接转成文字描述，再走文本向量化进入 RAG。这个方法对“文档里的数据可视化结果”尤其有效——传统 OCR 提取饼图上的标签文字很费劲，多模态模型一句话就能描述清楚“哪几个部分占比最高”。

这三种用法对应的技术路线是一样的，都是视觉编码器 + 文本解码器，只是在任务目标上做了不同设计。

3.2 结构化输出与向量化：图文入库的两种路线

用多模态模型把图片转成文字后，入库路线有两条，取决于你的知识库用途：

• 轻量路线：图片转纯文本 → 按已有文本链路切块 → embedding → 入库。改动最小，适合文档型知识库。
• 增强路线：保留图片，同步生成文字描述和结构化字段，图片本身做视觉向量化。适合素材检索、商品库、看图问答类产品。

我在一个工程图纸管理项目上就试过第二种路线。图纸的标题栏、技术要求说明通过多模态模型抽取成结构化记录，同时调用视觉模型把图纸缩略图编码成向量。用户搜“冷却水管径标注”，纯文本路线能命中文字说明，视觉路线能直接搜到相似的图纸图像，两条路线的检索结果融合，效果比单一条好非常多。

但这里要提醒：视觉向量化需要额外的模型部署与存储开销，一般中小项目先别急着上，等文本路线的效果确认无法满足需求再补不迟。

3.3 成本与效果权衡：不是所有图片都要走大模型

多模态模型不是免费午餐，它的问题集中在两方面：模型服务成本高，单次图片处理开销远大于开源 OCR；推理延迟明显，批量处理大量页面的时间开销非常大。

我的经验是分层处理，别一刀切：

• 印刷体文字、票据、截图：用 PaddleOCR 这类轻量方案，快且便宜。
• 复杂图表、手写体、图文逻辑判断：用多模态模型，质量优先。
• 格式高度统一、量大且字段明确：用云厂商专用 OCR 接口做结构化输出，比大模型更稳定。

有个真实的统计：一个 2000 页的技术手册，全程走多模态模型解析，耗时约几个钟头，费用按 API 计费也是一笔不小的开销；同一份文档用 PaddleOCR + 后处理，十分钟内跑完，成本可忽略。选型之前，先看你的数据长什么样，再决定花多少钱，一分钱一分货，但没必要为用不上的货付钱。

4. 九种 PDF 工具选型：按场景各取所需

PDF 解析工具的大坑在于“没有一个万能工具”。我按实际项目经验整理了九种工具的表现，先看全景，再逐个讲解适用场景，方便你直接对照选型。

4.1 九种工具全景一览

4.2 纯文本场景：pdfplumber 与 PyMuPDF

如果你的 PDF 是文本型的，且内容以报告、说明书、规范为主，pdfplumber 和 PyMuPDF 二选一就行。

pdfplumber 的强项在于它能拿到每个文字块在页面上的坐标（bounding box）。这个能力在处理表格时非常好用——它可以把表头、行、列按坐标切出来，输出成一个二维结构。我处理财务报表时，用过 pdfplumber 的extract_table()方法直接得到表格二维数组，省了大量手写规则的时间。

PyMuPDF 则是速度王者。纯文本提取比 pdfplumber 快一个数量级，大 PDF 批量跑非常合适。更关键的一点是，PyMuPDF 能把 PDF 页面渲染成图片（通过get_pixmap()），这就为“文本提取失败时自动转到 OCR”，提供了统一技术基础。我的很多管道脚本同时引入这两个工具：先用 PyMuPDF 快速尝试，遇到高精度需求再交给 pdfplumber 补细节。

4.3 扫描件场景：pdf2image + OCR 与 Unstructured

扫描型 PDF 的解析逻辑是：先把 PDF 渲染成图片，再做 OCR。pdf2image 负责前者，PaddleOCR 或 Tesseract 负责后者。

这套组合最大的好处是自由度高，每一步都可以替换。我常用的参数：dpi=200或dpi=300。200 足够常规文档，300 用于件体较小或复杂表格的文档。分辨率调太低，识别率明显下降；调太高，图像体积暴涨，OCR 速度变慢。也可以先渲染再逐页 OCR，简单可靠。

Unstructured 则是另一个思路：它把 PDF 解析封装成了一个“全家桶”式的框架。你只要给它一个文件路径，它会自动决定用文本提取还是走 OCR，并且把结果按标题、段落、列表、表格分成不同的块（chunk）。这对 RAG 落地特别友好，因为切块本身就是知识库需要的形态。不过要注意，Unstructured 的本地版对一些复杂版式的处理效果一般，跑高精度解析时它的 API 服务会更好。

4.4 高精度复杂排版：Marker、LlamaParse 与 Nougat

当文档包含双栏排版、复杂表格、公式时，普通工具往往会“读错顺序”。比如双栏论文，如果不做版面分析，文本提取结果是左栏和右栏内容“交叉串读”。这时候就需要 Marker 这类专业工具。

Marker 是专门做 PDF 转 Markdown 的开源模型，它对双栏、图表、标题层级、公式都有不错的版面识别能力。我自己拿一批 IEEE 论文跑了 Marker，输出的 Markdown 结构基本保留了原文的标题层级，段落顺序也是对的，这是普通文本提取完全比不了的。代价是处理速度慢，单页耗时在一秒到几秒之间，批量化处理时需要排队。

LlamaParse 是 LlamaIndex 团队推出的在线解析服务，本质是“后台用大模型 + 多模态能力辅助做文档结构化”。它对 RAG 场景做了深度适配，返回的结果除了文本，还保留了标题层级、表格结构、元数据，直接用 LlamaIndex 框架的朋友基本无需再做额外清洗。需要注意的是，免费额度有限，大批量处理得考虑成本；另外它是在线服务，敏感文档要谨慎。

Nougat 则是 Meta 开源的一个“让 PDF 变 Markdown”的学术文献专用模型，它的独特优势在公式识别，可以处理复杂数学公式并转成 LaTeX。我拿数学论文测过一次，公式转换为 LaTeX 的准确率明显好过通用工具。但它对普通文档、PPT 报告这类内容效果就很一般，属于“专精”工具，普通项目不一定用得上。

4.5 便携与合规：pypdf 与云端 PDF API

最后说说 pypdf。它是一个极轻量的库，只有提取文本、合并页面、旋转页面这类基础能力。很多工具链实际内部都在用它。如果你的需求就是“从 PDF 里把正文文字拿到”，它对嵌入式的、版权方希望最大限度保护内容的 PDF 是首选，因为它不做任何网络请求，完全本地运行。

云端 PDF 解析 API 则是企业级场景的好帮手。各家云厂商都有自己的文档解析产品，以 PDF 抽取为主要能力，配合表格还原、版面分析和票据识别专用模型，准确率和结构化程度都远超通用自建方案。对于需要处理海量合同、发票、报关单这类表格化数据的团队，云端 API 节省的研发时间可能远超接口费用。

这里给一个更实际的经验：不要指望用一个工具解决所有 PDF。我的落地做法是“三层漏斗”：先用 PyMuPDF 快速提取，能取出文本的文档直接走正常解析流程；取不出文本的你再去 OCR；对OCR结果置信度仍然低的复杂版面，最后才上多模态大模型。这套漏斗能避免所有文档都跑重模型，性能和成本的平衡最好。

5. 实操：从零搭一条 PDF 转结构化文本流水线

理论讲完，直接上代码。我以 Python 为例，搭一条“文本型 PDF 直接提取、扫描型 PDF 自动 OCR”的解析流水线。这条链路是我项目中用得最顺手的模板，你可以直接拿去改。

5.1 环境准备与依赖安装

先装依赖。推荐用 Python 3.10 以上的环境：

pip install pymupdf pdfplumber paddleocr paddlepaddle pdf2image

如果你在 Windows 上使用 pdf2image，还需要自行安装 poppler，并把bin目录加入环境变量。在 macOS 上可以用 Homebrew 安装：

brew install poppler

这里有个小建议：PaddleOCR 的依赖比较多，装完以后最好跑一遍官方自带的测试图片，确认 GPU 或 CPU 环境都能正常推理，再开始批量处理。PaddleOCR 3.x 版本默认会自动下载模型权重，首次运行时会比较慢，属于正常现象。

5.2 代码拆解：提取文本、识别图片，输出切块结果

完整代码如下，我加了详细注释：

import fitz # PyMuPDF from paddleocr import PaddleOCR from pdf2image import convert_from_path # 使用 PaddleOCR 3.x 的多语言接口，这里以中英文为主 ocr = PaddleOCR(use_angle_cls=True, lang='ch') def extract_page_text(page, page_num): """优先提取 PDF 原生文本，没有文字层则用 OCR""" raw = page.get_text("text").strip() if raw: return raw, "native" # 渲染页面为图片，DPI 选 200 平衡速度与效果 pix = page.get_pixmap(dpi=200) img_path = f"temp_page_{page_num}.png" pix.save(img_path) result = ocr.ocr(img_path) texts = [] if result: for item in result: if item and len(item) > 0: for line in item: texts.append(line[1][0]) return "\n".join(texts), "ocr" def parse_pdf(pdf_path): doc = fitz.open(pdf_path) page_texts = [] for page_num in range(len(doc)): page = doc.load_page(page_num) text, source = extract_page_text(page, page_num) # 记录来源页码和解析方式，方便溯源 page_texts.append({ "page": page_num + 1, "source": source, "text": text, }) doc.close() return page_texts if __name__ == "__main__": result = parse_pdf("扫描版合同.pdf") for item in result[:3]: print(f"=== 第 {item['page']} 页（来源：{item['source']}）===") print(item["text"][:300])

这段代码的逻辑很直白：每一页先尝试get_text()，有文字就直接用；没有文字层，就把这一页渲染成图片，交给 PaddleOCR 识别。最后返回一个包含页码、解析方式、正文内容的字典列表，方便你后续做切块和入库。

我实际跑下来的关键是：不要每页都 OCR，很多混合型 PDF 只有前几页是扫描件，后面全是文本层，逐页判断可以省掉大量无效 OCR 调用。另外，get_text("text")返回的文本可能有大量空白换行，入库前记得做一次正则清洗。

5.3 入库前的清洗与元数据保留

解析输出的内容不能直接塞向量库，我习惯做这几步：

• 去除页眉页脚。用正则匹配页码、公司名称、链接等噪声，避免它们影响 embedding。
• 按语义切块。常见切块大小是 200~500 token，可以用 LangChain 的RecursiveCharacterTextSplitter做初步切分，再用针对 PDF 的结构信息（章节标题）做二次合并。
• 保留元数据。每一条 chunk 必须带着page、source（原文路径）、file_type` 这些字段。效果好的 RAG 项目，几乎都依赖元数据进行结果溯源和过滤。没有页码的 chunk，用户问“这个结论出自哪里”时你会很难受。

清洗完的文本，再走 embedding 模型转向量。这里不展开 embedding 选型，但也提一句：如果你的文档中中文为主，优先选择针对中文优化的向量模型，效果差距比想象中要大。

6. 常见问题与排查技巧实录

最后这部分，我分享几个真实踩过的问题和对应的排查思路。每个问题都来自实际项目，希望你能少走几轮弯路。

6.1 韩文、泰文等小语种 OCR 识别不了怎么办

有个很典型的现象：代码跑起来没问题，中文也能识别，但一遇到韩文内容，输出要么是空白，要么是乱码。原因几乎都出在语言模式上。

PaddleOCR 的lang参数需要明确指定语言，默认是英文和中文。想识别韩文，改成：

ocr = PaddleOCR(use_angle_cls=True, lang='korean')

如果用的是 Tesseract，则需要单独下载韩文语言包。Debian/Ubuntu 上安装方式是：

sudo apt install tesseract-ocr tesseract-ocr-kor

这在 Windows 上稍微麻烦点，需要手动到 Tesseract 的 tessdata 目录里放语言包文件。我遇到过一口锅：同事在 Windows 上给 Tesseract 装好了英文包，调用时指定lang='kor'，程序直接报错，原因就是语言包根本没放进去。提前把多语言包的加载路径检查一遍，可以避免这种低级问题。

6.2 PDF 没有文字层：复制出来全是乱码

这种情况通常是扫描型 PDF 或者某些加密 PDF 被转了图片。排查顺序是：

• 先用page.get_text("text")打一下，如果结果是空，就确认是扫描件。
• 用 pdf2image 或 PyMuPDF 把页面渲染出来，肉眼看一眼质量。如果图片本身模糊，尝试提高 DPI 到 300，并做一次灰度化和二值化再 OCR。
• 如果仍然识别效果差，考虑是不是文档底色复杂。可以先用图像处理工具做背景清除（比如 OpenCV 的阈值处理），再送 OCR。

记得我之前跑营业执照识别率低，后来发现是页面底色是浅黄，直接把背景过滤掉，识别率立刻上来。这类预处理技巧，比换更贵的 OCR 有效率得多。

6.3 表格数据提取后错乱对不上

解析带表格的 PDF，常见问题是：提取出来的表格行、列对不上，或者单元格里的值串到了另一个字段。这种情况我一般分两步排查：

第一步，看 PDF 是真表格还是“假表格”。有些 PDF 导出的表虽然视觉上是表格，但底层是分散的文字块，没有明显的表格结构。这时 pdfplumber 的extract_tables()结果往往不稳定，建议改用坐标方式手动切分。

第二步，试试 OCR 的表格还原能力。PaddleOCR 3.x 新增了表格结构识别模型，输出结果包含单元格坐标和行列信息，可以直接还原成二维表。实测在无表线表格、表格线模糊的场景下，识别结果优于纯文本解析。

如果表格结构特别复杂，比如多级表头、合并单元格，别浪费时间调开源工具，直接上云厂商的表格识别专用 API。一次调用就把结构化结果拿回来，省心且效果可靠。

6.4 图片长文本被截断、双栏论文怎么处理

多模态模型处理长图时，经常把长页面截断，或者漏掉底部的段落。我用的方法是“本来就该分页跑”：先切图，再把每个局部区域分别送模型，最后汇总。切图可以用 PaddleOCR 的检测框做动态切分，也可以直接用固定网格切成几个 patch。这样能显著提升大页面的识别完整度。

双栏论文的解析，典型的解法是先用版面分析把页面切成左右两栏，再分别提取文本。Marker 内部就是这么做的；如果用 Unstructured，可以设置strategy="hi_res"让它启动高精度版面分析。手工作业的话，也可以直接用 fitz 的page.get_text("blocks")拿文本块坐标，再人工按 x 坐标排序区分栏位。最笨的办法往往也最可靠，前提是你知道每一栏文本块的坐标范围。

6.5 调用云端 OCR 报“file format error”怎么排

云 OCR 接口返回 “file format error”，多数不是文件格式真错，而是请求体的编码问题。常见是直接把图片的 Base64 字符串传给接口，但没加data:image/png;base64,前缀。有些服务对传参名也有严格要求，比如字段名必须是image，传成file同样会报格式错误。

排查顺序是：先确认本地图片可正常打开；再确认 Base64 编码没有换行符；最后确认请求参数名和 Content-Type 和文档完全一致。我印象很深的一次，问题出在 Python 的base64.b64encode()返回的是 bytes，我没.decode()就直接传给了 HTTP 请求库，对方接口解析不了 bytes，报了格式错误。加一步解码就解决了。

6.6 本地 RAG 拆解工具选择建议

很多人在 mac 上搭建 RAG 知识库，找本地文本拆解工具时容易犯选择困难症。如果你是本地轻量使用，我推荐组合：PyMuPDF 做 PDF 文本提取，PaddleOCR 或 RapidOCR 做扫描件识别，LangChain 或 LlamaIndex 做切块与循环构建。这三个组合已经可以覆盖绝大多数本地文档场景。

如果只是纯文本 Markdown、TXT 的拆解，其实连 PDF 工具都用不上，交给切块器直接按段落切就行。不需要一开始就引入云服务，先本地跑通，再看是否需要升级到更专业的服务，这才是最实际的路径。

最后再讲一点我的实操体会：解析链条的“监控”非常重要。生产环境的 RAG 接入大量新文档时，一定要统计每一类文档的“无文本率”“OCR 空结果率”“平均切块数”，这些指标能帮你快速发现解析失败或质量骤降。没有监控的 RAG 知识库，就像没有仪表盘的车，开着心里完全没底。还有一个小技巧：无论用哪种解析方式，请务必保留“原文页码”作为元数据。我做了这么多项目，这是检索结果取得用户信任的关键一环——让用户能点回原文验证，才是一个真正可用的知识库。