56页扫描件，5分钟带页码答案！jina-ocr-v1+Elasticsearch RAG：表格全重建、手写也识别，无需分块代码

立即上手体验Elasticsearch：探索Elasticsearch Labs仓库中的示例笔记本，开始免费云试用，或直接在本地机器上运行Elasticsearch。

上传一份扫描版的56页植物指南，询问哪些树木能耐受浅层石灰岩土壤。不到五分钟，你就能得到答案，同时获得答案对应的页码以及可购买的适用植物。背后的检索增强生成（RAG）管道由两个托管组件构成：jina-ocr-v1读取每个扫描页面并返回表格结构完整的Markdown，Elasticsearch的semantic_text字段类型在数据摄取时对Markdown进行分块和向量嵌入。因此，你无需编写分块代码，也无需运行嵌入任务。混合检索在Claude Haiku 4.5生成基于事实的答案之前完成关键词与语义排名的融合，所有流程都在同一个项目内运行于Elastic Inference Service（EIS）之上。

这一点至关重要，因为组织依赖的大部分知识从未进入数据库。它们存在于PDF、扫描表单或拍摄的文档中，传统搜索无法读取这些内容。经典的光学字符识别（OCR）管道通过串联多个独立模型来完成工作——布局检测、文本识别、表格解析、阅读顺序还原，每个环节都有各自的成本和失败模式。新一代的视觉语言文档解析器通过单一模型推理即可完成同样的任务。当与支持向量的搜索引擎配合使用时，PDF（或其照片）在几分钟内就能变成可查询、可引用的知识来源。

将文档解析与混合搜索和RAG相结合，团队可以：

• 让表格、手写内容和复杂排版变得可搜索——这些内容正是关键词搜索和传统OCR的盲区。
• 以自然语言对文档提问，并获取带有页面级别引用的、有据可依的答案。
• 在单次查询中融合精确词匹配（如SKU或植物学名称）与语义匹配（含义与意图）。
• 将整个管道——包括解析和向量嵌入以及答案生成——全部保留在单一平台内，一份账单、一个安全边界。

Uploading a scanned plant guide PDF and asking the RAG chatbot which invasive plants to avoid

图1：用户上传一份扫描版56页植物指南，用自然语言提问。随后获得以指南为据的答案，附带页码引用和匹配的商品。

在本文中，我们将逐步演示如何为德克萨斯本土植物电商网站添加文档解析功能。（我很喜欢植物！）你可以上传指南，观看jina-ocr-v1解析每一页，将输出索引到以文档命名的Elasticsearch索引中，并通过RAG聊天机器人进行查询——它会按页码引用来源，并推荐目录中的商品。技术栈如下：

• Jina OCR (jina-ocr-v1)： 一种文档解析模型，通过单次多模态推理将页面图像转换为干净、结构化的Markdown。
• EIS： 随Elastic Cloud Serverless附带的GPU加速推理服务。EIS在预配置的chat_completion端点后面托管jina-ocr-v1，同时提供嵌入模型和对话式大语言模型（LLM）（本次构建中使用Claude Haiku 4.5），因此无需自行部署模型或管理GPU，也无需单独的供应商账户。EIS按token计量使用量，作为Serverless附加组件计费。各模型的当前费率请参见Elastic Cloud定价表。
• Elasticsearch： 将解析后的文档存储在semantic_text字段类型中，该类型在数据摄取时通过推理端点自动完成文本分块和向量嵌入，并通过倒数排名融合（RRF）提供词法与语义排名相融合的混合检索。
• React、TypeScript和Vite，搭配Express后端： 商店前端，扩展了文档上传页面（通过服务器发送事件流式传输解析进度）和悬浮聊天组件。Express层将所有凭据保留在服务端。

Architecture diagram of a RAG pipeline for scanned PDFs using jina-ocr-v1 and Elasticsearch

图2：架构图。上半部分为问题查询流向；下半部分为文档上传流程，jina-ocr-v1在索引前将页面转换为Markdown。

jina-ocr-v1与传统OCR管道有何不同？

jina-ocr-v1是单一模型——布局检测、文本识别、表格重建和阅读顺序还原在一次推理中全部完成。传统OCR管道则通过串联多个独立模型来完成同样的工作，分别负责布局检测、文本识别、表格解析和阅读顺序重建。该模型的输出专为检索而设计：

• 保留阅读顺序的结构化Markdown，章节标题保留为Markdown标题层级。
• 表格以HTML格式输出，数值完整保留，因此一份50州许可证费率表或植物养护对照表仍然是完整的表格。
• 手写内容以内联方式转录。
• 重复的页面装饰元素（包括页眉、页脚以及印刷页码）会被去除，确保不会污染检索结果；页码由数据摄取循环单独生成。

这种干净的结构正是后续分块、向量嵌入和来源引用可靠性的基础。该模型每次读取一页图像（在约2048 x 2048像素内保持可读性），因此需要有人来执行页面遍历循环。

页面循环在哪里运行：Jina Reader API、聊天补全API还是EIS

由谁来运行这个循环，就是架构决策的关键所在。

本文采用EIS路由——一个平台边界，页面循环只需在server/documents.js中编写几十行代码。

为什么扫描版植物指南是文档解析的硬核测试

一个演示语料只有具备挑战性才有说服力。我们的测试文档是Native and Adapted Landscape Plants: An Earthwise Guide for Central Texas，这是由奥斯汀市和德州AgriLife推广服务局共同编写的教育出版物，旨在帮助公众进行节水和生态友好型园艺。它是该市Grow Green计划背后的植物名录。这份56页的扫描文档正是基础PDF文本提取最容易出错的内容类型。几乎每一页都是密集的多栏表格，充满了缩略词（如″VL″表示极低水量，″B/E″代表Blackland Prairie和Edwards Plateau）、用于标记野生动物价值和抗鹿性的对勾符号、斜体的植物学名称，以及穿插在数据中的照片说明文字。一个能够完整重建这些表格及其数值的解析器，处理你的发票也绰绰有余。

Invasive plants table from a scanned guide, reconstructed by jina-ocr-v1 with every row intact

图3：指南中第50页的“需要避免的入侵植物”表格（含推荐的本地原生替代品种），由jina-ocr-v1完整重建。

植物主题也为文档智能提供了实际应用场景。宿主应用是一个德克萨斯本土植物商店，带有预置好的Elasticsearch商品目录：48种植物配有semantic_text描述，以及全文检索与混合搜索切换开关。加入文档智能后，购物者可以上传一份区域性种植指南，然后提问“哪些树木能耐受浅层石灰岩土壤？”他们将获得以指南为据的答案，包含页码引用和匹配的商品列表。

前置条件：Elastic Cloud账户、API密钥和一份扫描文档

• 一个Elastic Cloud账户（免费试用即可）。创建一个Elastic Cloud Serverless项目。向量数据库项目类型适合这种嵌入密集型工作负载。
• 在项目中，确认EIS模型列表中包含Jina OCR v1（.jina-ocr-v1-chat_completion）和Claude Haiku 4.5（.anthropic-claude-4.5-haiku-chat_completion）。两者均为预配置状态，无需任何部署操作。
• 一个具有索引读写和推理权限的Elasticsearch API密钥，以及你的项目端点URL。
• Node.js 20或更高版本、npm和git。
• 一份测试文档，例如上文链接的Native and Adapted Landscape Plants指南，或任何你自己的扫描版、表格密集型文档。

为扫描版PDF搭建RAG管道

步骤1： 克隆仓库并安装依赖。

git clone https://github.com/elastic/elastic-labs.git
cd elastic-labs/supporting-blog-content/jina-ocr-v1-hybrid-rag-elasticsearch
npm install

步骤2： 配置凭据。复制模板文件并填写你的项目值。.env文件已被gitignore忽略，因此密钥永远不会进入仓库。OCR端点已预配置，嵌入模型使用项目默认值，因此聊天模型是本次构建中唯一的模型选择，而且已经为你配置好了。

cp .env.example .env

ELASTICSEARCH_URL=https://<your-project>.es.<region>.elastic.cloud:443
ELASTICSEARCH_API_KEY=<your-api-key>
LLM_INFERENCE_ID=.anthropic-claude-4.5-haiku-chat_completion

步骤3： 预置商品目录。种子脚本会创建目录索引（long_description是一个文本字段，通过镜像映射到semantic_text，因此混合商品搜索立即可用）并批量加载48种植物。首次运行大约需要一分钟，因为Elasticsearch会在数据摄取时为每条描述生成向量嵌入。

npm run seed

步骤4： 在两个独立终端中分别启动后端和前端，先启动后端。

在第一个终端中，启动Express API。它监听3001端口（由.env中的PORT设置）并运行OCR管道和聊天功能。

npm run server

在第二个终端中，启动React应用的Vite开发服务器。它将会把/api调用代理到后端。

npm run dev

Vite会打印其服务地址，通常是http://localhost:5173。（如果5173被占用，它会自动选择下一个可用端口。）打开该地址即可；不要直接访问3001端口，因为它只暴露API。

Texas native plants storefront with a 48-plant catalog and full-text, hybrid and compare toggle

图4：带有预置48种植物目录的商店前端。顶部切换开关可在全文检索、混合搜索和并排对比模式之间切换。

OCR管道如何将扫描页面转换为Markdown

Documents页面是解析流程在屏幕上展开呈现的地方，而非在终端中。用户拖入PDF或照片，Express服务器运行一个四阶段管道，同时通过服务器发送事件将每个步骤实时流式传输回浏览器。

阶段1：将PDF页面渲染为图像

PDF在内存中被渲染为约1224 x 1584像素的PNG页面图像，不超过模型2048像素的可读性上限。拍摄的文档则以单页方式直接跳过此步骤。

阶段2：转录每一页并重建表格

每个页面图像以base64数据URL的形式发送到EIS端点，与任何视觉模型的调用方式完全相同。四页并行处理，并在重新组装时保持顺序：

const resp = await fetch(
  `${ES_URL}/_inference/chat_completion/.jina-ocr-v1-chat_completion/_stream`,
  {
    method: 'POST',
    headers: { Authorization: `ApiKey ${ES_API_KEY}` },
    body: JSON.stringify({
      messages: [{
        role: 'user',
        content: [
          { type: 'image_url',
            image_url: { url: `data:image/png;base64,${png}` } },
          { type: 'text',
            text: 'Transcribe this page into clean Markdown, preserving reading order. Represent tables as HTML tables.' }
        ]
      }]
    })
  });

每页完成后，浏览器会记录日志；例如“page 12: 2,572 characters of Markdown”。当任何一页产出第一个HTML表格时，服务器立即将其发送到前端，UI以完整样式实时渲染。观看一份密集的扫描植物表格以结构化HTML表格的形式重新出现，每个用水代码和高度范围都完好无损，这是整个演示中最令人信服的时刻。

Parsing 56 scanned PDF pages with jina-ocr-v1, showing a table extracted from page 6

图5：Documents页面解析过程中，包括进度条、逐页日志以及从第7页提取并实时渲染的表格。

阶段3：使用semantic_text索引并嵌入文档

不是将所有内容堆入一个通用文档索引，而是每次上传都会获得一个以文件名命名的独立索引：Native-and-Adaptive-Plants.pdf对应native-and-adaptive-plants。（索引跟随文件名，因此你的索引会与你上传的文件对应。）content字段作为全文文本被索引，并通过copy_to镜像到semantic_text字段——Elasticsearch会在数据摄取时自动对Markdown进行分块，并通过项目默认推理端点生成向量嵌入。因此，你无需编写分块代码或构建嵌入管道，也无需进行向量管理。

PUT native-and-adaptive-plants
{
  "mappings": {
    "properties": {
      "content":  { "type": "text", "copy_to": "content_semantic" },
      "content_semantic": { "type": "semantic_text" },
      "title":  { "type": "keyword" },
      "page_count": { "type": "integer" }
    }
  }
}

阶段4：在Elastic中查看新索引

文档已完成索引，UI会提示解析完成并建议你查看Elastic索引。打开你的项目，索引就静静地待在那里——以文档命名，已分块并完成向量嵌入。一个小型注册索引（doc-registry）会跟踪每个已解析的文档，以便聊天功能列出它们。

Parsing complete banner and the new Elasticsearch index shown in Kibana Index Management

图6：完成横幅显示新索引名称，同一索引在Elastic控制台中可见。

提问：混合检索与基于来源的答案生成

每个页面角落的叶片状聊天按钮会打开Plant advisor（植物顾问）。默认情况下，它会从“所有内容”（上传的指南和商品目录）中寻找答案。用户可以将范围缩小到单个文档或仅目录，但默认设置正是零售场景的核心所在。服务器通过三个步骤来回答问题：

1. 混合检索：词法与语义搜索如何协同

两个混合检索并行运行，一个在文档索引中，另一个在商品目录中。每个检索都使用RRF检索器，对同一文本的两类排名进行融合：词法匹配（捕捉精确术语，如“Quercus macrocarpa”或“VL”或价格）和语义查询（捕捉“岩石碱性土壤中生长的树木”这样的含义，即使原句中不包含这些词）。在这个语料上，混合检索始终能返回关键词匹配遗漏的植物；商店前端中的Compare（对比）视图可以精确展示任意查询下的差异。

"retriever": {
  "rrf": {
    "retrievers": [
      { "standard": { "query": { "match": { "content": question } } } },
      { "standard": { "query": { "semantic": { "field": "content_semantic",
          "query": question } } } }
    ]
  }
}

2. 来源提取与页码引用

高亮器（Highlighter）在此发挥作用。语义高亮器返回最匹配的嵌入分块，普通高亮器返回词法片段。页码从数据摄取循环嵌入的页面标记中恢复。每个来源都标注了指南名称和页码。

3. 答案生成：基于来源的Claude Haiku 4.5生成

来源、匹配的商品目录条目和问题一并发送给EIS上的Claude Haiku 4.5，并附上严格的基于来源的指令：仅根据来源回答，按名称和页码引用来源，只推荐目录中存在的商品，如果答案不在其中请明确说明。模型还会返回一行隐藏的SKU列表，用于记录其推荐的商品，服务器会从流中剥离该行；只有这些商品会被展示，因此当某个问题在商店中找不到答案时，系统会诚实地回答且不显示任何商品卡片。答案流式传输到聊天界面中，附有可展开的来源面板和下方折叠的“查看推荐”区域。

Plant advisor chat answering a low-water plants question using hybrid retrieval over the catalog

图7：Plant advisor回答“哪些植物最省水？”，答案流式输出，来源带页码标注。推荐商品折叠在下方。

针对你的索引文档可以尝试的查询

• 哪些树木能耐受浅层石灰岩土壤？（语义检索在此发挥作用。）
• 指南中关于Quercus macrocarpa说了什么？（词法检索识别精确的植物学名称。）
• 我应该避免哪些入侵植物，推荐的替代品种是什么？（答案存在于jina-ocr-v1重建的表格中。）
• 用水代码VL和M分别代表什么？（测试指南关键页上的图例表格。）

从扫描PDF到带引用的答案

一年前，这条管道需要布局模型、OCR引擎、表格解析器、分块服务、嵌入任务和一个向量数据库，各自独立部署。如今，两个托管组件就覆盖了从扫描页面到带引用答案的完整路径：jina-ocr-v1在一次推理中将像素转换为结构化Markdown，Elasticsearch的semantic_text字段在数据摄取时将该Markdown转化为可混合搜索的知识。

这份植物指南是你最棘手文档的替身。换成理赔表单、实验室报告、设备手册或供应商目录——上传、解析、按文档索引、提问。开始免费的Elastic Cloud试用，然后把管道指向你们团队最常抱怨的那份PDF。