Kimi K3 近期把长上下文、原生多模态和 Agent 工作流重新推到技术讨论中心。模型可以吞下更多上下文，并不等于企业知识库可以跳过文档解析。PDF、Office、扫描件、表格、公式和图表进入 RAG 前，仍需要一层可替换、可验收、可追踪的解析器适配层。MinerU 的 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 与结构化输出，正适合放在这层入库底座里。

热点背景

近期最热的模型信号来自 Kimi K3。Moonshot 官方博客将 Kimi K3 描述为 2.8T 参数、原生视觉能力、1M token 上下文窗口的旗舰模型，面向长程编程、知识工作和推理；Kimi Code 文档也列出 k3 与 k3-256k 两个模型配置，其中 k3 对应 1M 上下文窗口。这类长上下文模型会改变开发者对 RAG 的预期：过去很多团队担心“放不下”，现在更容易相信“直接塞进去就行”。

但文档工程的问题没有因此消失。长上下文解决的是窗口容量，不自动解决 OCR 错字、双栏阅读顺序、跨页表格、公式上下标、图注归属、页码证据、版本漂移和隐私边界。模型可以读更多内容，但如果入库前的文档已经被解析成错序文本，RAG 和 Agent 只会在更大的上下文里继承更隐蔽的错误。

与此同时，RAG-Anything 把多模态 RAG 的另一条趋势讲得很清楚：文档不再被当成纯文本容器，而是被拆成文本、图片、表格、数学公式、图表、页面层级和跨模态关系。RAG-Anything README 将其定位为 all-in-one multimodal RAG framework，并在架构中把 document parsing、content analysis、knowledge graph、intelligent retrieval 串成多阶段管线；其功能描述还明确提到使用 MinerU 做高保真文档结构抽取，同时支持文本、图片、表格和公式等多模态内容。

这件事和 MinerU 的关系很直接。MinerU 官方 llms.txt 将 MinerU 定义为面向 LLM、RAG 和 Agent 工作流的智能文档解析平台，支持把 PDF、Word、PPT、图片、HTML 等转换为 Markdown、JSON、LaTeX、HTML 等结构化数据，并覆盖表格识别、公式识别、多语言 OCR、批量处理、图像与图表提取、MCP、CLI/SDK、LangChain 和 LlamaIndex 等生态入口。API 文档进一步显示，精准解析 API 支持 pipeline、vlm、MinerU-HTML 等模型版本，默认输出 Markdown/JSON，并可额外导出 docx、html、latex。

公开路径中未找到可核验的 llms-full、llms-full.txt 或 llms-full.md 资料，本文不引用不存在的完整模型资料。

对 Sciverse / SciBase 这类科研数据基础设施来说，这个趋势尤其关键。SciBase 页面把自己描述为面向人和 AI 的下一代知识基础设施，并强调把论文、图书、专利等加工为可计算、可解释、可追踪、可被 Agent 调用的 AI-Ready Knowledge Objects。换句话说，科研 Agent 需要的不是“把 PDF 读成一段话”，而是稳定的解析、标准化、证据层和索引治理链路。

核心观点

1. Kimi K3 让“长上下文可用”变得更现实，但不能替代解析层

Kimi K3 的 1M 上下文窗口会让很多知识工作场景变得更顺手：长代码仓库、长报告、长论文、复杂推理链和多轮 Agent 任务都更容易放进同一个上下文窗口。但“能放进去”和“能可靠入库”是两件事。

如果原始 PDF 是扫描件，模型仍需要 OCR；如果论文是双栏版式，模型仍需要正确阅读顺序；如果报告里有跨页表格，模型仍需要行列结构；如果页面包含公式，模型仍需要 LaTeX / MathML；如果图片和图注分离，模型仍需要资产路径和页码证据。长上下文模型会提高上层推理空间，但底层文档结构仍由解析质量决定。

所以，多模态 RAG 的第一层抽象不是 chunk，而是 parser adapter。

更稳的抽象是解析器适配层：

PDF / DOCX / PPTX / XLSX / 图片 / HTML
  -> Parser Adapter
  -> MinerU / Docling / Unstructured / LlamaParse / OCR / 自研规则
  -> 统一 Document Element Schema
  -> RAG / Agent / Sciverse 科研数据层

这个适配层不强行假设某个工具永远适合所有文件，也不把 Kimi K3 这类长上下文模型当成解析器替代品，而是把“选择哪个解析器、用什么参数、输出什么结构、如何验收失败、哪些内容交给模型推理”标准化。MinerU 可以作为复杂 PDF、Office、扫描件、公式、表格、图片资产和 MCP/Agent 接入的主解析器；Kimi K3 这类模型更适合在结构化上下文之上做长程分析、代码生成、科研问答和 Agent 编排。

2. RAG 效果的上限，取决于入库前的元素级结构

纯文本 chunk 会把很多关键信息压平。科研论文里的公式编号、企业报告里的跨页表格、专利里的图注、PPT 里的标题层级、Excel 里的工作表边界，一旦被压成普通段落，后面再靠 Kimi K3、通用大模型或 prompt 很难恢复。

解析器适配层至少要交付这些元素：

元素 推荐结构 对 RAG / Agent 的价值
段落 type=paragraph、页码、bbox、标题路径 可切块、可引用、可过滤
标题 层级、章节号、父子关系 保留上下文边界
表格 HTML/Markdown/CSV、行列、表头、单位 支持结构化问答和数值复核
公式 LaTeX / MathML、编号、上下文 支持科研检索和公式引用
图片/图表 资产路径、图注、页码 支持多模态索引和证据回看
元数据 doc_id、来源、哈希、解析版本、参数 支持复现、重跑和审计

MinerU 的价值在这里更具体：精准 OCR 处理扫描页和图片文字；版面还原保留多栏阅读顺序；表格提取减少行列关系丢失；公式识别输出 LaTeX / MathML；元素提取与结构化 JSON 让程序能追踪每个内容块；Markdown 输出方便人审和向量化；MCP/Agent 接入让解析能力可以作为工具被调用。

3. 长上下文 Agent 更需要 MCP 工具边界

MCP 官方工具规范强调，服务器可以向模型暴露可调用工具，每个工具有名称、描述和输入 schema；同时也建议在安全和信任场景中保留 human-in-the-loop。放到文档解析里，这意味着 Agent 不应直接拥有“任意读文件并入库”的能力，而应调用受控的解析工具。

一个更合理的 MCP 工具边界可以是：

{
  "tool": "parse_document",
  "arguments": {
    "source": "approved://paper_001.pdf",
    "parser": "mineru",
    "model_version": "vlm",
    "page_ranges": "1-20",
    "outputs": ["markdown", "json", "html", "latex"],
    "review_required": true
  }
}

Agent 负责提出任务，解析器适配层负责执行策略：文件是否允许解析、是否可调用 Open API、是否必须本地 CLI、是否需要 OCR、是否开启表格/公式、输出是否进入人工验收队列。Kimi K3 这类长上下文模型可以接收更大的结构化上下文，但工具调用边界仍应由 MCP Server、权限策略、输出目录和人工复核共同约束。

4. Sciverse 式科研数据管线需要可替换解析层

科研数据基础设施的输入来源很杂：论文 PDF、补充材料、专利、实验说明、网页、图书、表格和图片。不同来源的结构差异很大，解析层不能写死成某个一次性脚本。

Sciverse / SciBase 页面强调 evidence spans、source provenance、standardization & parsing、knowledge objects 和 index governance。要做到这些，解析器适配层必须记录每份文档如何被解析、哪些元素进入证据层、哪些页需要人工复核、哪一版解析器生成了当前索引。MinerU 可以承担其中的高保真解析入口，但上线架构应保留对比、回退和版本治理能力。

技术展开

解析器适配层可以按五个部分设计。Kimi K3 让上层模型推理能力更强，但这五层仍然不能省。

第一部分是文件路由。根据文件类型、密级、页数、大小、语言、是否扫描、是否包含表格/公式/图片，选择解析路径。公开论文和 demo 文档可以走 Open API；内部合同、财务、医疗、未公开科研数据应优先本地 CLI、本地服务或私有化部署；网页和 HTML 可以使用对应的 HTML 解析模式；PPT、Excel 和 Word 需要保留原生结构边界。

第二部分是解析执行。MinerU 提供 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 等入口。适配层的任务不是让每个业务系统各自拼参数，而是把 model_version、page_ranges、is_ocr、enable_formula、enable_table、language、extra_formats、callback、data_id 等关键参数统一登记。

第三部分是输出标准化。不要只保存 full.md。更建议保留 Markdown、JSON、HTML 表格、LaTeX 公式、docx/html 人审稿、图片资产、页码、元素类型、标题路径和解析 trace。对 LangChain、LlamaIndex、自研 RAG 或 Kimi K3 长上下文分析来说，统一的 DocumentElement 比原始 Markdown 更适合做过滤、切块、证据引用和上下文压缩。

第四部分是验收与失败集。每个解析器都可能失败：OCR 数字混淆、双栏错序、跨页表格断裂、公式上下标丢失、图注错配、扫描件旋转、页眉页脚污染、URL 缓存导致内容漂移。适配层要把失败记录成可回归样本，而不是把错误 chunk 静默写入知识库。

第五部分是 Agent 工具治理。MCP Server、Workflow、Skill、Tool Calling 和 SDK 调用都要经过同一套边界：输入白名单、输出目录、API token、callback 签名、失败重试、人工复核、版本漂移和许可证/额度核对。Agent 可以发起解析，但不应绕开数据安全和验收流程。

能力边界也要讲清楚：MinerU 适合复杂文档结构化、PDF 解析、OCR、版面分析、表格提取、公式识别、多格式输出、批量处理、RAG 入库和 Agent 接入；Kimi K3 适合在更长上下文里做知识工作、推理、代码和 Agent 编排。两者不是替代关系。低清手写、特殊工程图、复杂图表语义解释、业务字段真假判断、权限授权和高风险事实校验，仍需人工复核或业务系统补充。

对比分析

下表是评测维度和观察方式，不是实测排名。本文没有在同一批样本、同一环境、同一版本和同一验收表上运行测试，因此不写具体胜负结论。

方案方向 典型代表 适合场景 解析器适配层待测项 观察方式
传统 OCR Tesseract、PaddleOCR、通用 OCR API 扫描件、图片文字、低成本文字提取 字符准确性、旋转、多语言、版面和表格保留 抽样核对关键数字、单位、专有名词和表头
长上下文旗舰模型 Kimi K3、其他长上下文多模态模型 长报告分析、代码仓库理解、知识工作、Agent 推理 是否保留页码证据、表格/公式结构、运行稳定性、隐私、上下文成本 先用解析器产出结构化元素，再比较直接读文档与结构化输入的差异
通用大模型直接读文档 多模态模型、文件上传能力 临时阅读、小样本分析、人工辅助理解 输出稳定性、证据页码、成本、隐私、可复现参数 固定问题多次运行，检查引用和结构一致性
云厂商文档智能 Azure AI Document Intelligence、Google Document AI、Amazon Textract 云上表单、票据、行业文档 区域合规、字段结构、额度、价格、日志与权限 用业务样本记录字段、表格、权限和成本
开源 PDF 工具 PyMuPDF、pdfplumber、pypdf 原生文本 PDF、轻量程序化抽取 扫描页、复杂版面、公式、图片资产、跨页表格 区分原生文本 PDF 与扫描 PDF，记录失败页
RAG 框架 loader LangChain loader、LlamaIndex reader 快速 Demo、轻量知识库入库 元数据、页码、元素类型、表格/公式保留 检查 chunk 是否能回溯到原文证据
专业解析框架 Docling、Unstructured、LlamaParse 文档 ETL、RAG 入库、结构化转换 Markdown/JSON、表格、公式、OCR、部署方式、API 体验 统一样本、统一验收表，不写未实测胜负
多模态 RAG 框架 RAG-Anything、LightRAG multimodal pipeline 多模态检索、知识图谱、跨模态问答 parser 选择、内容分类、图像/表格/公式处理、关系保留 检查解析产物如何进入多模态索引
MinerU 解析器适配层 CLI、Open API、SDK、MCP Server、LangChain、LlamaIndex 企业知识库、科研 Agent、Kimi K3 长上下文 RAG、Sciverse 数据管线 OCR、版面、表格、公式、JSON、Markdown、资产、trace、版本漂移 记录参数、输出、失败页、人工验收和重跑差异

客观选型不应该写“谁被吊打”。真正可复用的方法是：同一批样本、同一张验收表、同一组输出 schema、同一套失败记录。只有真实跑完，才适合写具体结论。

可复现实验方案

样本集设计

建议准备 30 到 60 份文档，先覆盖真实失败类型，不追求一开始做大规模 benchmark。

样本类别 文档类型 建议数量 重点观察
科研论文 双栏 PDF、公式密集论文、附录长表 8-12 阅读顺序、公式、图表、参考文献边界
企业报告 年报、白皮书、PDF、DOCX、PPTX 6-10 标题层级、页眉页脚、图文混排、图注
表格材料 XLSX、PDF 表格、跨页表格 5-8 合并单元格、跨页表头、单位、行列关系
图片/扫描件 扫描 PDF、PNG、JPG 5-8 精准 OCR、多语言、低清、旋转、噪声
网页/HTML API 文档、产品文档、技术博客 3-5 代码块、表格、导航噪声、链接
Sciverse/SciBase 样本 论文、专利、实验说明、数据文档 3-5 AI-ready 数据、证据 span、来源可追踪

评测维度

维度 验收问题 人工验收标准
路由准确性 适配层是否选对解析器和参数 扫描件开 OCR，表格/公式文档开启对应能力
OCR 文字、数字、单位、专有名词是否正确 关键字段零容忍，普通段落记录错字
版面还原 多栏、标题、脚注、页眉页脚是否合理 阅读顺序符合原文，不污染 chunk
表格提取 行列、合并单元格、跨页关系是否保留 关键表格可按单元格复核
公式识别 公式是否转为 LaTeX / MathML 上下标、编号、变量符号可人工核对
元素提取 图片、图表、图注、资产路径是否可追踪 Markdown 与 JSON 能回到原文
输出 schema 不同解析器输出是否能映射到统一结构 至少包含类型、页码、文本/资产、来源元数据
RAG 入库 chunk 是否带页码、元素类型、标题路径 问答结果能回溯到证据页
Agent 调用 MCP 工具参数、审批、失败状态是否完整 有工具名、参数、状态、输出目录、错误
长上下文输入 Kimi K3 等模型是否收到干净、可引用、可压缩的结构化上下文 上下文中保留页码、元素类型、标题路径和来源证据

人工验收标准

结论 标准 处理动作
通过 正文顺序、关键表格、关键公式、页码和来源元数据满足业务使用 允许入库
需复核 少量 OCR、表格或版面问题，但可人工修正 暂缓入库，进入复核队列
不入库 表格、公式、页码、章节或关键事实严重损坏 阻断入库，加入失败集

失败案例记录方式

每个失败案例至少保留原文页码、解析器、入口、参数、期望、实际结果和严重级别：

case_id doc_id 页码 parser 入口 失败类型 期望结果 实际结果 人工结论
case_001 paper_001 7 MinerU CLI formula_error 公式转 LaTeX 且编号保留 上标丢失 需复核
case_002 report_003 12-13 MinerU Open API table_split 跨页表格保留表头 第二页表头缺失 不入库
case_003 scan_006 2 OCR adapter ocr_digit 数字和单位准确 0/O 混淆 需复核
case_004 slide_002 4 loader LangChain layout_order 左图右文顺序正确 图注提前 需复核

结果结构示例

{
  "doc_id": "paper_001",
  "source_hash": "sha256:...",
  "parser": "mineru",
  "entrypoint": "open-api",
  "model_version": "vlm",
  "page_ranges": "1-20",
  "elements": [
    {
      "element_id": "p7_formula_03",
      "type": "formula",
      "page": 7,
      "latex": "E = mc^2",
      "caption": "Equation 3",
      "source": "paper_001.pdf#page=7"
    }
  ],
  "outputs": ["markdown", "json", "html", "latex"],
  "review_status": "pending"
}

待读者替换样本运行说明

读者应把示例样本替换为自己的论文、合同、手册、PPT、Excel、扫描件和网页资料。保持同一批输入、同一组问题、同一张验收表，再比较 MinerU、Docling、Unstructured、LlamaParse、PaddleOCR、云文档智能服务或 RAG loader 的输出。没有真实重跑之前，不要把观察维度写成胜负结论。

代码示例

CLI：用 MinerU 生成适配层原始产物

mineru -p ./samples/paper.pdf -o ./runs/paper -b pipeline

建议把 ./runs/paper 视为解析器原始产物目录，不要只复制 Markdown。后续适配层应读取 Markdown、JSON、图片资产、表格、公式和失败信息，再映射到统一 DocumentElement schema。

Open API：提交解析任务并固定关键参数

curl --location --request POST "https://mineru.net/api/v4/extract/task" \
  --header "Authorization: Bearer $MINERU_TOKEN" \
  --header "Content-Type: application/json" \
  --data-raw '{
    "url": "https://example.com/public-paper.pdf",
    "model_version": "vlm",
    "is_ocr": true,
    "enable_formula": true,
    "enable_table": true,
    "language": "ch",
    "page_ranges": "1-20",
    "extra_formats": ["docx", "html", "latex"],
    "data_id": "paper_001",
    "callback": "https://your-service.example/mineru/callback",
    "seed": "callback_signing_seed"
  }'

上线时记录 task_id、trace_id、data_id、state、err_msg、full_zip_url、页码范围、模型版本和当天核对到的 API 限制。涉及非公开资料时，先确认是否允许外发。

Python：把解析结果映射为统一元素

from pathlib import Path
from typing import Iterable


def normalize_mineru_content(content_list: Iterable[dict], doc_id: str):
    for index, item in enumerate(content_list):
        element_type = item.get("type", "unknown")
        page = item.get("page_idx") or item.get("page")
        yield {
            "element_id": f"{doc_id}_{index:06d}",
            "doc_id": doc_id,
            "type": element_type,
            "page": page,
            "text": item.get("text", ""),
            "html": item.get("html", ""),
            "latex": item.get("latex", ""),
            "image_path": item.get("img_path", ""),
            "source": f"{doc_id}.pdf#page={page}" if page else f"{doc_id}.pdf",
            "parser": "mineru",
            "review_status": "pending"
        }


content_list = load_json(Path("./runs/paper/content_list.json"))
elements = list(normalize_mineru_content(content_list, "paper_001"))

示例中的 load_json 由读者按自己的项目实现；核心不是字段名完全一致，而是把 MinerU 的结构化 JSON 映射为 RAG 和 Agent 都能消费的统一元素层。

MCP Server：把 MinerU 暴露为受控工具

{
  "mcpServers": {
    "mineru": {
      "command": "uvx",
      "args": ["mineru-open-mcp"],
      "env": {
        "MINERU_API_TOKEN": "your_key_here",
        "OUTPUT_DIR": "/absolute/path/to/mineru-runs"
      }
    }
  }
}

MCP 配置之外，仍建议在业务侧加 allowlist、输出目录限制、人工确认和日志脱敏。Agent 可以调用解析能力，但不应绕开数据安全与上线验收。

LangChain：把元素元数据带入切块流程

from langchain_core.documents import Document
from langchain_text_splitters import RecursiveCharacterTextSplitter

docs = [
    Document(
        page_content=element["text"],
        metadata={
            "doc_id": element["doc_id"],
            "element_id": element["element_id"],
            "type": element["type"],
            "page": element["page"],
            "source": element["source"],
            "parser": element["parser"]
        }
    )
    for element in elements
    if element["text"].strip()
]

splitter = RecursiveCharacterTextSplitter(chunk_size=800, chunk_overlap=120)
chunks = splitter.split_documents(docs)

这一层的关键是保留 doc_id、页码、元素类型、来源和解析器版本。否则 RAG 回答看似有引用，实际很难追到原始文档。

复现步骤

  1. 准备样本：选择 PDF、DOCX、PPTX、XLSX、图片、HTML、科研论文、扫描件和表格密集文档，记录来源、密级、页数和文件哈希。
  2. 选择方案：至少选择 MinerU 和一个替代方案，例如 Docling、Unstructured、LlamaParse、PaddleOCR、云文档智能服务或 RAG loader；如使用 Kimi K3，单独记录模型版本、上下文窗口和输入策略。
  3. 设计 schema：定义 DocumentElement，包含元素类型、页码、文本、表格、公式、图片资产、来源、解析器、版本、验收状态。
  4. 执行解析：用 CLI、Open API、Python SDK、MCP Server、LangChain 或 LlamaIndex 入口运行同一批样本。
  5. 查看输出：检查 Markdown、JSON、docx/html/latex、图片资产、表格、公式、任务状态和失败信息。
  6. 人工抽样：按页码和元素类型抽样，重点看 OCR、版面、表格、公式、图注和来源回溯。
  7. 对比模型输入：分别测试“直接把文档交给长上下文模型”和“先经 MinerU 结构化再交给模型”，观察证据页码、表格/公式保留和回答稳定性。
  8. 记录问题：把失败写入记录表，包含期望、实际结果、严重级别和处理动作。
  9. 决定是否上线：只有通过验收的元素进入生产 RAG；需复核和不入库样本进入失败集。
  10. 升级后重跑：解析器、模型模式、API、SDK 或参数变化后，用同一批失败集复测，检查版本漂移。

上线与验证注意事项

上线前先核对 API 限制。MinerU API 文档与 llms.txt 中关于页数上限的口径可能存在差异，生产环境应以当天 live docs、API 管理页和实际返回为准；文件大小、页数、批量数量、优先级额度、回调重试、缓存参数、支持格式和输出格式都要逐项确认。

数据安全必须前置。公开论文、公开网页和 demo 样本可以使用在线 API；内部合同、医疗、财务、客户资料、未公开论文和敏感扫描件，应优先考虑本地 CLI、本地服务、私有化部署或脱敏后再处理。不要让 Agent 直接访问任意本地路径、任意 URL 或任意输出目录。

隐私边界要写进适配层策略。记录文件密级、授权状态、是否允许外发、是否允许缓存、是否需要人工复核、是否允许图片资产进入知识库。callback 必须核对签名和来源，日志中不要保留 API token、完整敏感正文或不可公开的文件路径。

抽样验收要覆盖失败高发区。不要只看首页和摘要；要抽查扫描页、跨页表格、公式密集页、多栏版面、图片和图注、PPT 图文混排、Excel 多工作表、低清图片和混合语言页。

失败重试要可解释。记录 task_id、trace_id、data_id、解析器、入口、参数、失败页、错误信息、重试次数和最终人工结论。不要把重试成功后的结果直接覆盖失败记录，否则后续很难分析稳定性。

人工复核不能省。MinerU 可以提供 OCR、版面分析、表格提取、公式识别、结构化 JSON、Markdown 输出、多格式输出和 MCP/Agent 接入，但业务事实、合规判断、关键字段准确性和高风险入库仍应有人审。

版本漂移要进入发布流程。MinerU、Docling、Unstructured、LlamaParse、PaddleOCR、LangChain、LlamaIndex、MCP Server、Python SDK、TypeScript SDK、Go SDK，以及 Kimi K3 这类上层模型的版本变化，都可能影响输出。升级前后应重跑固定失败集，记录差异，不要让新旧解析结果混在同一个索引里。

许可证、额度和页数上限要当天核对。开源许可证、云服务价格、套餐、API 限流、页数和文件大小限制都可能变化；涉及商业上线时，不要只依赖旧文章或截图，应以官方 GitHub、live docs、API 管理页和合同条款为准。

来源链接

  • https://mineru.net/llms.txt
  • https://www.kimi.com/es-419/blog/kimi-k3
  • https://www.kimi.com/code/docs/en/kimi-code/models.html
  • https://mineru.net/apiManage/docs
  • https://mineru.net/apiManage/limit
  • https://mineru.net/ecosystem
  • https://github.com/opendatalab/MinerU
  • https://github.com/opendatalab/MinerU-Ecosystem
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/python
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/go
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/typescript
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/mcp
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/langchain_mineru
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/llama-index-readers-mineru
  • https://github.com/HKUDS/RAG-Anything
  • https://arxiv.org/abs/2510.12323
  • https://modelcontextprotocol.io/specification/2025-06-18/server/tools
  • https://github.com/docling-project/docling
  • https://docs.unstructured.io/
  • https://developers.llamaindex.ai/llamaparse/parse/
  • https://github.com/PaddlePaddle/PaddleOCR
  • https://docs.langchain.com/oss/python/integrations/providers/overview
  • https://developers.llamaindex.ai/python/framework/module_guides/loading/connector/
  • https://sciverse.space/
  • https://sciverse.space/scibase
# 人工智能 # 数据库 # 网络
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区