后端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 的 C 绑定xberg.h/ 生成的 ALEF 接口讲解如何把“可复用结果缓存”use_cache与“质量后处理”enable_quality_processing放入同一次抽取配置中一并生效。读完本文你将掌握这两个开关的默认值、底层执行链路缓存命中判断、quality_score 计算并能直接照抄 C 代码片段在自己的项目中启用“缓存 质量评分”的组合抽取。关联文档config_cache_quality.md对应契约测试config_cache_quality.json。场景速览一次配置同时启用缓存与质量评分在 xberg 中配置通过 JSON 字符串传入 C API。下面的代码一次性开启了两个开关enable_quality_processing质量后处理与use_cache结果缓存然后对同一个 URI 执行抽取#include assert.h #include stdint.h #include stdio.h #include stdlib.h #include string.h #include xberg.h int main(void) { XBERGAlefHandle input_handle xberg_extract_input_from_json({\kind\:\uri\,\uri\:\https://example.com/pdf/fake_memo.pdf\}); XBERGAlefHandle config_handle xberg_extraction_config_from_json({\enable_quality_processing\:true,\use_cache\:true}); XBERGAlefHandle result xberg_extract(input_handle, config_handle); xberg_extract_input_free(input_handle); xberg_extraction_config_free(config_handle); xberg_extraction_result_free(result); return EXIT_SUCCESS; }xberg_extract_input_from_json将 JSON 形式的输入描述这里是一个uri类型的输入转换为内部句柄xberg_extraction_config_from_json把 JSON 配置反序列化为ExtractionConfigxberg_extract执行抽取主流程返回结果句柄三个*_free调用负责释放输入、配置与结果句柄避免内存泄漏。三个句柄类型均来自生成的 C 头文件xberg.hFFI 仓库见 crates/xberg-ffi/include/xberg.h。该片段与契约测试的配置完全一致实测会返回quality_score字段见 config_cache_quality.json。两个开关的默认值与底层字段这两个开关在 xberg 的ExtractionConfig结构中均有对应的布尔字段定义于 core.rs/// Enable caching of extraction results #[serde(default default_true)] pub use_cache: bool, /// Enable quality post-processing #[serde(default default_true)] pub enable_quality_processing: bool,需要注意默认值都是true见impl Default中的use_cache: true, enable_quality_processing: truecore.rs。也就是说即使你的 JSON 配置只写{use_cache: true}质量后处理默认也是开着的反过来只开质量开关缓存也默认生效。二者在 JSON 中同时出现互不冲突缓存决定“结果是否可复用”质量后处理决定“结果是否附带质量评分”属于抽取流水线中两个不同阶段缓存发生在提取器执行前后质量评分发生在后处理阶段。serde(deny_unknown_fields)表明配置结构是严格校验的未知字段会被拒绝所以拼写错误会直接导致xberg_extraction_config_from_json解析失败。同样的配置组合在契约测试中也有体现config_cache_quality.json 的config段设置了use_cache: true, enable_quality_processing: true并断言返回结果results[0].quality_score落在[0.0, 1.0]区间内assertions。use_cache缓存键、命中判定与失效缓存功能的实际执行位于 file.rs 的extract_file_with_extractorif !config.use_cache || config.cache_ttl_secs Some(0) { return extract_file_uncached(path, mime_type, config).await; } let content_hash crate::cache::blake3_hash_file(path)?; let config_hash hash_extraction_config(config, mime_type); let cache_key format!({content_hash}_{config_hash});几个关键点关闭方式use_cache false或cache_ttl_secs 0都会强制走无缓存路径缓存键构成blake3内容哈希 配置哈希hash_extraction_config(config, mime_type) MIME 类型任何一项变化都会导致键不同从而避免脏命中命中与回填命中后直接rmp_serde::from_slice反序列化返回缓存结果L302-L308未命中则执行真实抽取再把结果rmp_serde::to_vec序列化后写入缓存L310-L316因此返回给调用方的始终是完整、结构一致的ExtractedDocument命名空间与 TTLcache_namespace与cache_ttl_secs两个可选字段core.rs分别控制缓存分区隔离与过期时间适合多租户或对时效敏感的场景。配置组合对缓存键的影响同一个文件、同一个enable_quality_processing开关组合才会命中同一条缓存。由于use_cache、cache_ttl_secs、cache_namespace属于“缓存控制字段”在计算配置哈希前会被归一化剔除见 file.rs而质量开关属于参与哈希的配置因此本文示例中“开质量 开缓存”与“关质量 开缓存”会使用不同的缓存键互不污染。enable_quality_processing质量评分的计算与语义质量后处理由QualityProcessor插件实现位于 quality_processor.rs。它是一个PostProcessor运行在Early处理阶段当config.enable_quality_processing为true时计算质量分并写入ExtractedDocument::quality_scoreL22-L27。quality_score 描述的是什么源码注释明确指出L29-L31The score describes retained text, not extraction completeness or recall. Callers must inspectExtractedDocument::processing_warningsseparately.即quality_score衡量的是保留文本的整洁度/可读性不是抽取完整性或召回率。需要判断“是否漏掉了某些内容”时应单独检查processing_warnings。契约测试也印证了这一点config_cache_quality.json只断言分数在[0.0, 1.0]之间L52-L59并未把它解释为“抽取质量”的全面指标。OCR 置信度对分数封顶的影响一个值得注意的实现细节当 OCR 已运行且识别出足够多的词达到MIN_OCR_WORDS_FOR_CONFIDENCE_FLOOR阈值时质量分会被单词数加权的 OCR 平均置信度封顶issue #1669。这是因为纯文本形状启发式只读保留文本本身——一页 OCR 仅以 81% 置信度识别的文本看起来可能“形状干净”而得 1.0 分。该均值通过ConfidenceSignals::ocr_confidence_from_elements/ocr_confidence_from_pages折入与ExtractionConfidence::ocr_aggregate使用同一套权重避免两处漂移issue #1694。这意味着在“扫描件 OCR 质量评分”的组合下质量分会诚实反映识别置信度而不会虚高。与其他配置的配合质量开关还可以与result_format、content_filter文档“家具”过滤、postprocessor等字段协同。在 engine/mod.rs 与 merge.rs 中enable_quality_processing与use_cache均参与配置合并与覆盖解析Rust 测试也验证了默认值、显式覆盖等场景见 mod.rs 的test_default_config默认两者均为true。完整可运行的调用流程总结构造输入句柄xberg_extract_input_from_json({\kind\:\uri\,\uri\:\https://example.com/pdf/fake_memo.pdf\})构造配置句柄xberg_extraction_config_from_json({\enable_quality_processing\:true,\use_cache\:true})执行抽取xberg_extract(input_handle, config_handle)按需读取results[0].quality_score0.01.0依次释放三个句柄。实战注意事项首次执行时缓存未命中会执行完整抽取并回填第二次对同一文件、同一配置执行时命中缓存返回速度显著提升且quality_score不会丢失结果以序列化形式完整保存若想验证缓存是否生效可临时将use_cache设为false对比耗时若文件内容变化内容哈希改变或抽取配置变化配置哈希改变缓存键自动失效无需手动清理对时效性敏感的数据如定时抓取的网页建议配合cache_ttl_secs控制缓存有效期。延伸阅读配置结构定义crates/xberg/src/core/config/extraction/core.rs缓存执行链路crates/xberg/src/core/extractor/file.rs质量处理器插件crates/xberg/src/text/quality_processor.rs契约测试与断言fixtures/contract/config_cache_quality.jsonC 绑定头文件crates/xberg-ffi/include/xberg.h赞分享后端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 OCR 流水线深度解析后端执行、结果缓存与跨后端质量不变量Xberg OCR 流水线深度解析后端执行、结果缓存与跨后端质量不变量 Xberg 的 OCR 能力覆盖图像、PDF 扫描件到多后端的完整链路其设计核心是「后端AI 应用NLPxberg C 绑定实战extract_batch 批量提取中的安全限制与 max_content_size 尺寸上限xberg C 绑定实战extract_batch 批量提取中的安全限制与 max_content_size 尺寸上限 本篇基于 xberg 仓库中自动生成的后端AI 应用NLPxberg C 绑定实战用 VLM 视觉大模型liter-llm配置 OCR 文本提取xberg C 绑定实战用 VLM 视觉大模型liter llm配置 OCR 文本提取 本文以 xberg 的 C FFI 接口为主线讲解如何配置 VL后端AI 应用NLP上一篇favico.js插件开发模板快速创建符合规范的扩展下一篇Broadcast Box前端深度解析React TypeScript构建现代化播放器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考