后端AI 应用NLP【免费下载链接】xbergPolyglot document intelligence with a Rust core: extract text, metadata, images, tables, and structured data from 106 formats across 140 file extensions, plus code intelligence for 371 languages. Fifteen bindings, with CLI, REST API, and MCP server.项目地址https://gitcode.com/gh_mirrors/kr/xberg点击查看免费下载txtai-xberg是 Xberg 官方提供的 txtai 集成包它把 Xberg 的文档提取能力107 种格式、按需 OCR、原生分块包装成一个可调用管道XbergPipeline输出(id, text, tags)三元组直接喂给txtai.Embeddings.index从而让 PDF、DOCX、HTML 等异构文档在数行代码内完成提取 → 分块 → 向量化 → 语义检索全链路。读完本文你将掌握该集成的安装、两种调用模式仅提取 / 直接建索引、配置项语义、错误处理约定以及extract_batch批量提取在 Rust 核心与 Python 绑定层之间的真实调用链。集成定位与工作流txtai-xberg的职责非常聚焦不做检索只负责把文档变成 txtai 能直接消费的语料。它站在 Xberg 的 Python 绑定之上依赖xberg1.2.8把 Xberg 的异步提取 API 封装为符合 txtai pipeline 习惯的可调用对象。整体数据流如下Extract提取— Xberg 解析源文档并在必要时运行 OCR如扫描版 PDF 或图片型文档。Chunk分块— 当传入的ExtractionConfig启用 chunking 时Xberg 把每篇文档切分为语义分片并在分片中保留标题路径heading_path与页码上下文。Flatten展平—to_documents把提取结果展平为(id, text, tags)元组启用分块时每个 chunk 一条未启用时每个文件一条。Index索引— 把元组直接交给txtai.Embeddings.index即可获得关键词、向量或混合检索能力。安装pip install txtai-xberg包要求 Python 3.10pyproject.toml中requires-python 3.10classifiers 覆盖 3.103.14。如果环境中还没有 txtai可通过 extra 一并安装pip install txtai-xberg[txtai]该 extra 声明了txtai9.7,10的版本区间基础依赖xberg1.2.8,2会自动带入 Xberg 的 Python 绑定见 pyproject.toml。包内部结构极简src/txtai_xberg/下只有pipeline.py核心实现、__init__.py与py.typed并以py.typed提供类型标注支持。快速开始提取并索引分块文档from txtai import Embeddings from txtai_xberg import XbergPipeline from xberg import ChunkingConfig, ExtractionConfig pipeline XbergPipeline( configExtractionConfig(chunkingChunkingConfig(max_characters1000, overlap200)), ) documents pipeline.to_documents([report.pdf, notes.docx]) embeddings Embeddings(pathsentence-transformers/all-MiniLM-L6-v2, contentTrue) embeddings.index(documents) for result in embeddings.search(quarterly revenue, 3): print(result[id], result[text])要点分块 ID 约定分块文档的id形如source#chunk_index例如report.pdf#0、report.pdf#1。这一格式由 pipeline.py 中的_chunk_to_index_document生成测试test_to_documents_chunk_ids_are_unique也验证了 ID 的唯一性。不分块的默认行为如果不传chunking配置to_documents每文件只产出一条文档id即源路径本身。contentTrue的意义txtai 在保存向量时会同时存储原始文本检索结果因此能直接返回命中的段落文本。仅提取模式不建索引直接读内容XbergPipeline本身是可调用对象适合只想拿提取结果、不进入索引环节的场景。按 txtai pipeline 惯例传入单个字符串返回单个文档传入列表按输入顺序返回文档列表from txtai_xberg import XbergPipeline pipeline XbergPipeline() doc pipeline(report.pdf) print(doc[content]) # 提取出的 markdown 文本 print(doc[metadata][title]) # 见下方 metadata 字段说明 docs pipeline([report.pdf, notes.docx]) # 列表输入 → 列表输出每个返回的文档是包含content与metadata两个键的字典ExtractionDocumentTypedDict。metadata的结构由 pipeline.py 中的DocumentMetadata定义字段如下字段类型含义sourcestr输入路径原样回传mime_typestr检测到的 MIME 类型如application/pdf、text/plaintitlestr \| None文档标题无标题时可能为Noneauthorslist[str] \| None作者列表languageslist[str] \| None检测到的语言列表page_countint页数无分页概念的格式为 0测试 test_pipeline.py 断言了这六个键是稳定存在的元数据契约即使值可能为None键也始终出现。两个方法族怎么选to_documents/ato_documents__call__/acall返回(id, text, tags)元组{content, metadata}字典粒度每 chunk 一条或每文件一条每文件一条适用场景直接喂给Embeddings.index直接读取提取后的文本一句话总结要建索引用to_documents要读文本用__call__。两者内部共享同一条提取路径只是对结果的展平方式不同。深入to_documents的数据契约to_documents返回IndexDocument即tuple[str, str, dict[str, Any]]对应 txtaiEmbeddings.index接收的(id, text, tags)格式。tags是元数据映射txtai 会将其存储并在contentTrue时暴露为可过滤的列。未启用分块时每条文档的tags包含四个键见 pipeline.pysource源路径mime_typeMIME 类型title标题page_count页数启用分块时每个 chunk 的tags扩展到九个键见 pipeline.py这是做切片级过滤检索的关键source、mime_type、title文档级信息透传chunk_index该 chunk 在文档内的序号从 0 开始total_chunks文档总分块数heading_path标题路径如Introduction Methods保留文档层级上下文first_page/last_pagechunk 覆盖的页码范围token_countchunk 的 token 数这些键的完整性由测试 test_to_documents_with_chunking_splits_into_multiple_segments 直接断言。有了source chunk_index first_page/last_page你在检索命中后可以精确回溯到原文位置这对 RAG 场景的引用溯源非常实用。深入用 ExtractionConfig 控制提取行为XbergPipeline(config...)接受任意 Xberg 的ExtractionConfig这是打通提取行为的统一入口。ExtractionConfig定义于 packages/python/xberg/options.py字段众多与本文场景最相关的几组OCR 控制from xberg import ExtractionConfig, OcrConfig pipeline XbergPipeline( configExtractionConfig( output_formatmarkdown, # 输出文本格式plain / markdown 等 ocrOcrConfig(languageeng), # OCR 语言设置 force_ocrTrue, # 即使是可搜索 PDF 也强制走 OCR max_concurrent_extractions8, # 批量提取的并发上限 ), )相关字段output_format默认plain控制内容文本格式设为markdown时可保留标题、列表、表格等结构测试 test_config_drives_extraction_output_format 验证了 plain 与 markdown 两种输出内容确实不同。force_ocr默认False强制对所有页面 OCR另有force_ocr_pages按 1 起始页码指定特定页、ocr_strategy默认auto、disable_ocr等更细粒度开关。max_concurrent_extractions批量提取时 Xberg 内部 worker 池的并发上限默认由 Xberg 决定。extraction_timeout_secs默认 600批量提取中每个文件的超时时间。原生分块ChunkingConfigfrom xberg import ChunkingConfig ChunkingConfig( max_characters1000, # 每个 chunk 的最大尺寸单位随 sizing 而定 overlap200, # chunk 间重叠量 trimTrue, # 是否裁剪 chunk 边界空白 chunker_typetext, # 分块器类型text / markdown sizingcharacters, # 尺寸度量方式如 characters / tokens table_chunkingsplit # 超过尺寸上限的 markdown 表格如何处理 )ChunkingConfig的完整定义在 packages/python/xberg/options.pymax_characters与overlap的默认值分别为 1000 与 200。从源码结构看它还支持embedding/sparse_embedding/late_interaction等可选配置用于生成 chunk 级向量以及preset预设与topic_threshold语义主题边界检测说明 Xberg 的 chunking 不止于字符切分还具备语义与结构感知能力。测试中用ChunkingConfig(max_characters200, overlap20)处理三页 PDF fixture得到多个 chunk 并逐项校验了chunk_index、total_chunks、heading_path、first_page、last_page、token_count等标签字段。同步与异步两种 API 形态XbergPipeline的方法都成对出现同步异步说明__call__(docs)acall(docs)返回提取文档字典/字典列表to_documents(docs)ato_documents(docs)返回(id, text, tags)列表同步版本通过asyncio.run桥接 Xberg 的异步 API见 pipeline.py因此不能在已运行的事件循环内调用同步方法——在 async 代码中请改用acall/ato_documents。测试 test_ato_documents_matches_sync 验证了同步与异步版本产出完全一致的结果。错误处理ExtractionFailedError批量提取时若部分输入失败管道不会静默跳过而是抛出ExtractionFailedError。该异常对象的errors属性持有 Xberg 的ExtractionErrorItem列表每个错误项包含index失败输入在输入列表中的位置便于定位是第几个文件source失败的源路径code数值错误码message错误描述异常信息会把所有失败项汇总为可读的明细见 pipeline.py。设计上有一个值得注意的细节由于 Xberg 的result.results只包含成功项若直接按输入顺序 zip 会产生错位因此实现选择任何失败立即抛错而非部分成功pipeline.py 的注释说明了这一点。测试 test_missing_file_raises_with_error_index 验证了缺失文件场景下index与source的正确性。底层原理一次原生批量调用管道性能的关键在于_extractpipeline.py它把每个路径包装为ExtractInput(uripath)然后一次调用extract_batch而不是逐个文件循环调用。extract_batch定义于 Python 绑定层 packages/python/xberg/api.py签名如下async def extract_batch( inputs: list[ExtractInput], config: ExtractionConfig | None None, ) - ExtractionResult:它会把 Python 侧的ExtractInput/ExtractionConfig转换为 Rust 绑定类型再进入 Rust 核心的批处理器对应 crates/xberg/src/api/handlers.rs。ExtractInput的定义在 packages/python/xberg/options.pykind默认uri输入类型uri对应本地路径 /file:/// HTTP(S) URLbytes对应原始字节uri路径或 URLmime_type/filename可选的 MIME 与文件名提示configper-input 提取覆盖批量输入会被分发到 Xberg 内部 worker 池并发执行并发上限由max_concurrent_extractions控制这正是原文档强调extract_batch比逐个循环更快的实现基础——并发在 Rust 核心内完成Python 侧只承担一次 FFI 编组开销。测试覆盖行为即契约integrations/python/txtai/tests/test_pipeline.py的测试用例几乎逐条锁定了上文描述的行为可作为集成用法的活文档输入形态单路径返回单个字典列表返回按序列表单元素列表仍返回列表空列表返回空列表。元数据真实性HTML fixture 的mime_type包含html、title为Sample HTML DocumentPDF fixture 的page_count 3、mime_type application/pdf、title is NoneDOCX fixture 的title DOCX DemoTXT 的page_count 0。配置透传默认构造时_config为None传入的ExtractionConfig原样存储——说明管道本身不修改配置一切行为由 Xberg 核心解释。分块行为分块 ID 唯一、首 chunk ID 为source#0、tags 键集合严格匹配。这些 fixturesample.pdf、sample.docx、sample.html、sample.txt位于 integrations/python/txtai/tests/fixtures/你可以在本地复现整套测试来验证集成行为。小结txtai-xberg的价值在于把两件事做薄而做透提取交给 Xberg107 种格式 按需 OCR 原生分块检索交给 txtai关键词 / 向量 / 混合。它的全部复杂性收敛在一个XbergPipeline类里——传入ExtractionConfig控制提取to_documents产出索引就绪的(id, text, tags)ExtractionFailedError兜底批处理失败。若你的 RAG 管线需要处理多格式文档这个集成提供了从文件到语义检索的最短路径。更多 Xberg 提取 API 与配置细节可查阅 packages/python/xberg/api.py 与 packages/python/xberg/options.pytxtai 本身的用法可参考其官方文档。赞分享后端AI 应用NLP【免费下载链接】xbergPolyglot document intelligence with a Rust core: extract text, metadata, images, tables, and structured data from 106 formats across 140 file extensions, plus code intelligence for 371 languages. Fifteen bindings, with CLI, REST API, and MCP server.项目地址https://gitcode.com/gh_mirrors/kr/xberg点击查看免费下载相关推荐Xberg 接入 SurrealDBsurrealdb-xberg 文档入库、去重与混合检索实战指南Xberg 接入 SurrealDBsurrealdb xberg 文档入库、去重与混合检索实战指南 surrealdb xberg 是 Xberg 文档提取后端AI 应用NLPOptiScaler深度解析重构跨平台AI超分辨率的技术壁垒OptiScaler深度解析重构跨平台AI超分辨率的技术壁垒 在显卡技术日益碎片化的今天AI超分辨率技术已成为游戏性能优化的关键战场。NVIDIA的DLSS图形学游戏开发Xberg 文档智能引擎实战指南107 种格式统一提取、OCR 与多语言绑定全景解析Xberg 文档智能引擎实战指南107 种格式统一提取、OCR 与多语言绑定全景解析 导读 Xberg 是一个以 Rust 为核心的多语言文档智能引擎把任意后端AI 应用NLP上一篇TypeGraphQL与Koa GraphQL性能对比基准测试结果下一篇Vue CLI 模式Modes与环境变量Environment Variables完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
