后端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 仓库文档 docs-site/src/snippets-generated/go/summarization/summarization_abstractive_smoke.md讲解如何在 Go 语言中通过github.com/xberg-io/xberg/packages/go绑定调用 Xberg 的 LLM 驱动的摘要Abstractive Summary功能。读完本文你将掌握ExtractionConfig、SummarizationConfig与LlmConfig三者的配置关系、XBERG_LLM_API_KEY或OPENAI_API_KEY环境变量的作用以及如何在提取流程中接入openai/gpt-4o-mini这类模型并获得DocumentSummary结果并了解其在 Rust 核心层的真实实现路径。关联文档概述该文档是 Xberg 仓库中由 alef 工具自动生成的 Go 语言示例片段fixture元数据如下字段值idfixture_go_summarization_abstractive_smokelanguage / targetgoleveltypecheckside_effectserver前置依赖requires无文档核心内容是一段可直接运行的 Go 程序通过xberg.Extract(input, config)对https://example.com/text/book_war_and_peace_1p.txt的 URI 进行提取并在ExtractionConfig中开启摘要功能最终打印result.Results[0].Summary。文档同时注明当XBERG_LLM_API_KEY或OPENAI_API_KEY未设置时该示例会被自动跳过。该片段属于仓库docs-site/src/snippets-generated/下跨语言 smoke 测试矩阵的一部分在 go/csharp/python/rust 等 15 种绑定语言中都有同构版本本文聚焦 Go 绑定并辅以 Rust 核心实现佐证。为什么需要 Abstractive 摘要Xberg 的文档摘要能力由内置的 summarization 后处理器post-processor提供支持两种策略见 crates/xberg/src/types/summary.rsExtractive抽取式默认策略。纯 Rust 实现基于 chunk 图上的 TextRank 算法TF-IDF 余弦相似度建图 PageRank确定性强、速度快、无需外部服务可编译进包括 WASM 与 Android 在内的所有目标。Abstractive生成式由 LLM 重新组织语言生成摘要。依赖liter-llm与summarization-llmfeature并必须配置LlmConfig其 token 用量会被记录到ExtractedDocument::llm_usage中。当需要概括性、可读性更强的摘要、而不仅仅是抽取原文句子时Abstractive 是合适的选择——这也是本文示例文档所演示的场景。逐行解析 Go 示例代码1. 引入绑定包import ( fmt xberg github.com/xberg-io/xberg/packages/go )github.com/xberg-io/xberg/packages/go是仓库内 packages/go 目录下的 Go 绑定通过 cgo/FFI 调用 Rust 核心。绑定中SummaryStrategy为字符串枚举类型见 packages/go/binding.goSummaryStrategyExtractive extractive纯 Rust TextRank默认SummaryStrategyAbstractive abstractiveLLM 生成2. 构造提取输入func ptrT any *T { return value } input : xberg.ExtractInput{ Kind: ptr(xberg.ExtractInputKindURI), URI: ptr(https://example.com/text/book_war_and_peace_1p.txt), }示例采用 URI 输入ExtractInputKindURIXberg 会先抓取该文本资源再进入提取管线。这里ptr泛型辅助函数用于把字面量转为指针因为绑定中大量配置字段是可选指针类型。3. 开启摘要并配置 LLMconfig : xberg.ExtractionConfig{ Summarization: xberg.SummarizationConfig{ Strategy: ptr(xberg.SummaryStrategyAbstractive), MaxTokens: ptr(uint32(150)), Llm: xberg.LlmConfig{ Model: openai/gpt-4o-mini, Temperature: ptr(float64(0.0)), MaxTokens: ptr(uint64(200)), }, }, }对应的 Go 绑定结构体定义见 packages/go/binding.go字段类型说明Strategy*SummaryStrategy摘要策略默认抽取式设为abstractive时启用 LLMMaxTokens*uint32摘要输出目标长度tokens不设置则由后端决定默认值Llm*LlmConfigLLM 后端配置Extractive时被忽略Abstractive时必填配置要点Model采用 liter-llm 的路由格式provider/model示例使用openai/gpt-4o-mini。Temperature: 0.0让生成更确定、可复现。MaxTokens: 200是模型生成上限而SummarizationConfig.MaxTokens: 150是提示词中要求的摘要目标长度二者含义不同。4. 执行提取并读取摘要result, err : xberg.Extract(input, config) if err ! nil { panic(err) } fmt.Printf(%v\n, result.Results[0].Summary)成功时Summary为DocumentSummary结构见 packages/go/binding.goText string摘要正文纯文本段落Strategy SummaryStrategy产生该摘要的策略TokenCount *uint32摘要近似 token 数可选环境变量与 LLM 凭据文档明确提示当XBERG_LLM_API_KEY或OPENAI_API_KEY未设置时该示例会被自动跳过。原因是LlmConfig.api_key为可选字段见 crates/xberg/src/core/config/llm.rs当api_key为None时liter-llm 会回退到该 provider 的标准环境变量——对 OpenAI 兼容模型即OPENAI_API_KEYXberg 统一支持XBERG_LLM_API_KEY作为全局凭据入口。因此在运行示例前请至少设置其中一个变量export XBERG_LLM_API_KEYsk-... # 或 export OPENAI_API_KEYsk-...深入 Rust 核心Abstractive 摘要的实现路径后处理器与处理阶段摘要功能由内置插件SummarizationProcessor实现见 crates/xberg/src/plugins/processor/builtin/summarization.rs运行阶段ProcessingStage::Middle触发条件ExtractionConfig.summarization为Some空内容content.trim().is_empty()时直接跳过调用链Extract(input, config) └─ pipeline 提取文本内容 └─ SummarizationProcessor.process └─ strategy Abstractive └─ run_abstractive └─ summarize_with_llm(text, llm_config, max_tokens) ├─ truncate_input(text, 128 * 1024) # 输入截断保护 ├─ build_prompt(trimmed, target_tokens) └─ complete_text(llm_config, prompt, summarisation_abstractive)关键实现事实见 crates/xberg/src/text/summarization/llm.rsDEFAULT_MAX_TOKENS 256SummarizationConfig.max_tokens未设置时使用的摘要目标长度MAX_PROMPT_INPUT_CHARS 128 * 1024输入文本按 UTF-8 边界截断到约 128 KiB按 ~4 字符/token 估算约 32k tokens防止大文档撑爆上下文提示词模板要求模型产出单个紧凑的散文段落禁止列表、Markdown 格式、标题或对摘要本身的评论并要求保留命名实体、数字与原文语气生成的摘要会写入result.summaryLLM 用量LlmUsage来源标记为summarisation_abstractive追加到result.llm_usage。配置校验若strategy Abstractive但llm未设置处理器会返回校验错误Abstractive summarisation requires SummarizationConfig.llm to be set若未启用summarization-llmcargo feature则报Abstractive summarisation requires the summarization-llm cargo feature见 crates/xberg/src/plugins/processor/builtin/summarization.rs。LLM 调用失败时不会中断提取而是向result.processing_warnings推入一条summarization_abstractive来源的警告。LlmConfig 完整参数参考LlmConfig是 Xberg 各 LLM 功能VLM OCR、VLM embeddings、结构化提取、摘要共享的配置类型见 crates/xberg/src/core/config/llm.rs核心字段如下字段类型默认/说明modelstring必填liter-llm 路由格式如openai/gpt-4o、anthropic/claude-sonnet-4-20250514、groq/llama-3.1-70b-versatileapi_keyOptionString为空时回退 provider 标准环境变量如OPENAI_API_KEYbase_urlOptionString自定义 provider 端点timeout_secsOptionu64请求超时默认 60smax_retriesOptionu32最大重试次数默认 3temperatureOptionf64采样温度max_tokensOptionu64生成 token 上限top_pOptionf64核采样概率校验范围[0.0, 1.0]stopOptionVecString停止序列统一以列表表达seedOptioni64随机种子用于可复现输出presence_penalty/frequency_penaltyOptionf64均校验范围[-2.0, 2.0]reasoning_effortOptionString扩展思考模型级别low/medium/high/minimal/maxextra_bodyOptionValue供应商特有参数guardrails、safety settings 等headersOptionHashMap附加 HTTP 头网关/自定义认证providersOptionVecLlmProviderConfig自定义 OpenAI 兼容网关/自托管模型服务器bedrockOptionBoxBedrockConfigAWS Bedrock 配置region、显式凭据max_concurrencyOptionusize全局同配置 provider 并发上限None表示不限制max_response_bytesOptionusize单次响应体字节上限Some(0)会在校验阶段被拒绝安全实现细节LlmConfig与BedrockConfig均手工实现了Debugapi_key、header 值、AWS 凭据等敏感字段在日志中一律以[redacted]呈现见 crates/xberg/src/core/config/llm.rs配置时无需担心凭据泄漏到调试输出。跨语言一致性该 smoke 示例在同构文档矩阵中覆盖了 15 种绑定语言包括 go、c、csharp、dart、elixir、java、kotlin-android、php、python、ruby、rust、swift、typescript、wasm、zig均位于docs-site/src/snippets-generated/lang/summarization/summarization_abstractive_smoke.md。各语言遵循同一套SummarizationConfig/LlmConfig/DocumentSummary语义Go 中的配置方式可直接迁移到其他绑定。Rust 原生侧可直接构造ExtractionConfig { summarization: Some(SummarizationConfig { strategy: SummaryStrategy::Abstractive, ... }) }调用xberg::extract获得同样结果。运行与验证将示例保存为main.gomodule 需声明对github.com/xberg-io/xberg/packages/go的依赖设置凭据环境变量见上文运行go run .期望输出形如{Text:... Strategy:abstractive TokenCount:0x...}其中Text为模型生成的散文式摘要Strategy为abstractiveTokenCount为近似的 token 计数。仓库内对应的 Rust 测试crates/xberg/src/plugins/processor/builtin/summarization.rs验证了后处理器的行为可作为对照。小结本文以 Xberg Go 绑定的 smoke 文档为骨架完整解析了 Abstractive 摘要从 Go 配置到 Rust 核心的调用路径ExtractionConfig.Summarization开启功能SummarizationConfig决定策略与目标长度LlmConfig提供模型与采样参数最终结果落在DocumentSummary。配合XBERG_LLM_API_KEY/OPENAI_API_KEY环境变量即可快速跑通端到端流程。若不需要外部 LLM将Strategy切回extractive即可获得纯本地、确定性的 TextRank 摘要。赞分享后端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 绑定下的抽象式Abstractive文档摘要基于 FFI 的 LLM 摘要配置与调用实战xberg C 绑定下的抽象式Abstractive文档摘要基于 FFI 的 LLM 摘要配置与调用实战 本文以 xberg 仓库中为 C 语言生成的摘要后端AI 应用NLPxberg Elixir 文档摘要实战abstractive / extractive 双策略配置与实现原理xberg Elixir 文档摘要实战abstractive / extractive 双策略配置与实现原理 本指南以 xberg 官方 Elixir 绑定中后端AI 应用NLP使用 C 调用 Xberg 为文档生成摘要Abstractive 与 Extractive 双策略实战使用 C 调用 Xberg 为文档生成摘要Abstractive 与 Extractive 双策略实战 本指南围绕 XbergRust 核心的多语言文档智能后端AI 应用NLP上一篇终极指南掌握ImageSharp的WebP格式编解码与性能优化技巧下一篇Puma异常处理机制ErrorLogger与请求级错误隔离创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
后端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 仓库文档 docs-site/src/snippets-generated/go/summarization/summarization_abstractive_smoke.md讲解如何在 Go 语言中通过github.com/xberg-io/xberg/packages/go绑定调用 Xberg 的 LLM 驱动的摘要Abstractive Summary功能。读完本文你将掌握ExtractionConfig、SummarizationConfig与LlmConfig三者的配置关系、XBERG_LLM_API_KEY或OPENAI_API_KEY环境变量的作用以及如何在提取流程中接入openai/gpt-4o-mini这类模型并获得DocumentSummary结果并了解其在 Rust 核心层的真实实现路径。关联文档概述该文档是 Xberg 仓库中由 alef 工具自动生成的 Go 语言示例片段fixture元数据如下字段值idfixture_go_summarization_abstractive_smokelanguage / targetgoleveltypecheckside_effectserver前置依赖requires无文档核心内容是一段可直接运行的 Go 程序通过xberg.Extract(input, config)对https://example.com/text/book_war_and_peace_1p.txt的 URI 进行提取并在ExtractionConfig中开启摘要功能最终打印result.Results[0].Summary。文档同时注明当XBERG_LLM_API_KEY或OPENAI_API_KEY未设置时该示例会被自动跳过。该片段属于仓库docs-site/src/snippets-generated/下跨语言 smoke 测试矩阵的一部分在 go/csharp/python/rust 等 15 种绑定语言中都有同构版本本文聚焦 Go 绑定并辅以 Rust 核心实现佐证。为什么需要 Abstractive 摘要Xberg 的文档摘要能力由内置的 summarization 后处理器post-processor提供支持两种策略见 crates/xberg/src/types/summary.rsExtractive抽取式默认策略。纯 Rust 实现基于 chunk 图上的 TextRank 算法TF-IDF 余弦相似度建图 PageRank确定性强、速度快、无需外部服务可编译进包括 WASM 与 Android 在内的所有目标。Abstractive生成式由 LLM 重新组织语言生成摘要。依赖liter-llm与summarization-llmfeature并必须配置LlmConfig其 token 用量会被记录到ExtractedDocument::llm_usage中。当需要概括性、可读性更强的摘要、而不仅仅是抽取原文句子时Abstractive 是合适的选择——这也是本文示例文档所演示的场景。逐行解析 Go 示例代码1. 引入绑定包import ( fmt xberg github.com/xberg-io/xberg/packages/go )github.com/xberg-io/xberg/packages/go是仓库内 packages/go 目录下的 Go 绑定通过 cgo/FFI 调用 Rust 核心。绑定中SummaryStrategy为字符串枚举类型见 packages/go/binding.goSummaryStrategyExtractive extractive纯 Rust TextRank默认SummaryStrategyAbstractive abstractiveLLM 生成2. 构造提取输入func ptrT any *T { return value } input : xberg.ExtractInput{ Kind: ptr(xberg.ExtractInputKindURI), URI: ptr(https://example.com/text/book_war_and_peace_1p.txt), }示例采用 URI 输入ExtractInputKindURIXberg 会先抓取该文本资源再进入提取管线。这里ptr泛型辅助函数用于把字面量转为指针因为绑定中大量配置字段是可选指针类型。3. 开启摘要并配置 LLMconfig : xberg.ExtractionConfig{ Summarization: xberg.SummarizationConfig{ Strategy: ptr(xberg.SummaryStrategyAbstractive), MaxTokens: ptr(uint32(150)), Llm: xberg.LlmConfig{ Model: openai/gpt-4o-mini, Temperature: ptr(float64(0.0)), MaxTokens: ptr(uint64(200)), }, }, }对应的 Go 绑定结构体定义见 packages/go/binding.go字段类型说明Strategy*SummaryStrategy摘要策略默认抽取式设为abstractive时启用 LLMMaxTokens*uint32摘要输出目标长度tokens不设置则由后端决定默认值Llm*LlmConfigLLM 后端配置Extractive时被忽略Abstractive时必填配置要点Model采用 liter-llm 的路由格式provider/model示例使用openai/gpt-4o-mini。Temperature: 0.0让生成更确定、可复现。MaxTokens: 200是模型生成上限而SummarizationConfig.MaxTokens: 150是提示词中要求的摘要目标长度二者含义不同。4. 执行提取并读取摘要result, err : xberg.Extract(input, config) if err ! nil { panic(err) } fmt.Printf(%v\n, result.Results[0].Summary)成功时Summary为DocumentSummary结构见 packages/go/binding.goText string摘要正文纯文本段落Strategy SummaryStrategy产生该摘要的策略TokenCount *uint32摘要近似 token 数可选环境变量与 LLM 凭据文档明确提示当XBERG_LLM_API_KEY或OPENAI_API_KEY未设置时该示例会被自动跳过。原因是LlmConfig.api_key为可选字段见 crates/xberg/src/core/config/llm.rs当api_key为None时liter-llm 会回退到该 provider 的标准环境变量——对 OpenAI 兼容模型即OPENAI_API_KEYXberg 统一支持XBERG_LLM_API_KEY作为全局凭据入口。因此在运行示例前请至少设置其中一个变量export XBERG_LLM_API_KEYsk-... # 或 export OPENAI_API_KEYsk-...深入 Rust 核心Abstractive 摘要的实现路径后处理器与处理阶段摘要功能由内置插件SummarizationProcessor实现见 crates/xberg/src/plugins/processor/builtin/summarization.rs运行阶段ProcessingStage::Middle触发条件ExtractionConfig.summarization为Some空内容content.trim().is_empty()时直接跳过调用链Extract(input, config) └─ pipeline 提取文本内容 └─ SummarizationProcessor.process └─ strategy Abstractive └─ run_abstractive └─ summarize_with_llm(text, llm_config, max_tokens) ├─ truncate_input(text, 128 * 1024) # 输入截断保护 ├─ build_prompt(trimmed, target_tokens) └─ complete_text(llm_config, prompt, summarisation_abstractive)关键实现事实见 crates/xberg/src/text/summarization/llm.rsDEFAULT_MAX_TOKENS 256SummarizationConfig.max_tokens未设置时使用的摘要目标长度MAX_PROMPT_INPUT_CHARS 128 * 1024输入文本按 UTF-8 边界截断到约 128 KiB按 ~4 字符/token 估算约 32k tokens防止大文档撑爆上下文提示词模板要求模型产出单个紧凑的散文段落禁止列表、Markdown 格式、标题或对摘要本身的评论并要求保留命名实体、数字与原文语气生成的摘要会写入result.summaryLLM 用量LlmUsage来源标记为summarisation_abstractive追加到result.llm_usage。配置校验若strategy Abstractive但llm未设置处理器会返回校验错误Abstractive summarisation requires SummarizationConfig.llm to be set若未启用summarization-llmcargo feature则报Abstractive summarisation requires the summarization-llm cargo feature见 crates/xberg/src/plugins/processor/builtin/summarization.rs。LLM 调用失败时不会中断提取而是向result.processing_warnings推入一条summarization_abstractive来源的警告。LlmConfig 完整参数参考LlmConfig是 Xberg 各 LLM 功能VLM OCR、VLM embeddings、结构化提取、摘要共享的配置类型见 crates/xberg/src/core/config/llm.rs核心字段如下字段类型默认/说明modelstring必填liter-llm 路由格式如openai/gpt-4o、anthropic/claude-sonnet-4-20250514、groq/llama-3.1-70b-versatileapi_keyOptionString为空时回退 provider 标准环境变量如OPENAI_API_KEYbase_urlOptionString自定义 provider 端点timeout_secsOptionu64请求超时默认 60smax_retriesOptionu32最大重试次数默认 3temperatureOptionf64采样温度max_tokensOptionu64生成 token 上限top_pOptionf64核采样概率校验范围[0.0, 1.0]stopOptionVecString停止序列统一以列表表达seedOptioni64随机种子用于可复现输出presence_penalty/frequency_penaltyOptionf64均校验范围[-2.0, 2.0]reasoning_effortOptionString扩展思考模型级别low/medium/high/minimal/maxextra_bodyOptionValue供应商特有参数guardrails、safety settings 等headersOptionHashMap附加 HTTP 头网关/自定义认证providersOptionVecLlmProviderConfig自定义 OpenAI 兼容网关/自托管模型服务器bedrockOptionBoxBedrockConfigAWS Bedrock 配置region、显式凭据max_concurrencyOptionusize全局同配置 provider 并发上限None表示不限制max_response_bytesOptionusize单次响应体字节上限Some(0)会在校验阶段被拒绝安全实现细节LlmConfig与BedrockConfig均手工实现了Debugapi_key、header 值、AWS 凭据等敏感字段在日志中一律以[redacted]呈现见 crates/xberg/src/core/config/llm.rs配置时无需担心凭据泄漏到调试输出。跨语言一致性该 smoke 示例在同构文档矩阵中覆盖了 15 种绑定语言包括 go、c、csharp、dart、elixir、java、kotlin-android、php、python、ruby、rust、swift、typescript、wasm、zig均位于docs-site/src/snippets-generated/lang/summarization/summarization_abstractive_smoke.md。各语言遵循同一套SummarizationConfig/LlmConfig/DocumentSummary语义Go 中的配置方式可直接迁移到其他绑定。Rust 原生侧可直接构造ExtractionConfig { summarization: Some(SummarizationConfig { strategy: SummaryStrategy::Abstractive, ... }) }调用xberg::extract获得同样结果。运行与验证将示例保存为main.gomodule 需声明对github.com/xberg-io/xberg/packages/go的依赖设置凭据环境变量见上文运行go run .期望输出形如{Text:... Strategy:abstractive TokenCount:0x...}其中Text为模型生成的散文式摘要Strategy为abstractiveTokenCount为近似的 token 计数。仓库内对应的 Rust 测试crates/xberg/src/plugins/processor/builtin/summarization.rs验证了后处理器的行为可作为对照。小结本文以 Xberg Go 绑定的 smoke 文档为骨架完整解析了 Abstractive 摘要从 Go 配置到 Rust 核心的调用路径ExtractionConfig.Summarization开启功能SummarizationConfig决定策略与目标长度LlmConfig提供模型与采样参数最终结果落在DocumentSummary。配合XBERG_LLM_API_KEY/OPENAI_API_KEY环境变量即可快速跑通端到端流程。若不需要外部 LLM将Strategy切回extractive即可获得纯本地、确定性的 TextRank 摘要。赞分享后端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 绑定下的抽象式Abstractive文档摘要基于 FFI 的 LLM 摘要配置与调用实战xberg C 绑定下的抽象式Abstractive文档摘要基于 FFI 的 LLM 摘要配置与调用实战 本文以 xberg 仓库中为 C 语言生成的摘要后端AI 应用NLPxberg Elixir 文档摘要实战abstractive / extractive 双策略配置与实现原理xberg Elixir 文档摘要实战abstractive / extractive 双策略配置与实现原理 本指南以 xberg 官方 Elixir 绑定中后端AI 应用NLP使用 C 调用 Xberg 为文档生成摘要Abstractive 与 Extractive 双策略实战使用 C 调用 Xberg 为文档生成摘要Abstractive 与 Extractive 双策略实战 本指南围绕 XbergRust 核心的多语言文档智能后端AI 应用NLP上一篇终极指南掌握ImageSharp的WebP格式编解码与性能优化技巧下一篇Puma异常处理机制ErrorLogger与请求级错误隔离创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 运行时)
