Agent 框架后端低代码RAG【免费下载链接】yao✨ All your agents and workspaces in one place, on every device you own. Track tasks on a board, accessible from desktop, mobile, browser, or API. Self-hosted.项目地址https://gitcode.com/gh_mirrors/ya/yao点击查看免费下载导读本文聚焦开源仓库 gh_mirrors/ya/yao 内置的yao-ocr技能tools/skills/yao-ocr/SKILL.md完整讲解其中两个 OCR 工具ocr_recognize与ocr_providers的用法、参数、识别类型与多提供商支持。文章以技能文档为主体结合 tools/ocr 目录下的 Go 源码逐层剖析内部实现读者读完将掌握如何用一条命令从图片/PDF 提取纯文本、表格 Markdown、发票等结构化 JSON如何在 VLM-OCR视觉语言模型与传统 OCR API百度、Google、Azure、PaddleOCR之间选择与切换以及多页 PDF 的结果组织方式。技能概览一个文件、两把“钥匙”yao-ocr技能定义在 tools/skills/yao-ocr/SKILL.md其 Frontmatter 声明name: yao-ocrdescription:将其定位为 OCR 文本识别专家凡是需要从图片或 PDF 中提取文字的场景都应当调用本技能包括发票、收据、身份证、银行卡、营业执照、表格、手写文档以及任意视觉文本内容。技能提供两个工具工具作用ocr_recognize使用 OCR 从图片或 PDF 中提取文字是核心识别入口ocr_providers列出当前可用的 OCR 提供商及其支持的识别类型从源码看两个工具分别对应 recognize.go 中的RecognizeHandler与 providers.go 中的ProvidersHandler它们以tools.ocr_recognize、tools.ocr_providers两个 process 的形式注册供tai tool命令行与 LLM Agent 调用。工具的 JSON Schema 定义在 recognize_schema.json 与 providers_schema.json 中。ocr_recognize核心识别工具的完整用法ocr_recognize从图片或 PDF 提取文字同时支持VLM-OCR视觉语言模型经 LLM 连接器接入和传统 OCR API百度、Google、Azure、PaddleOCR。基础用法纯文本输出tai tool ocr_recognize --source /path/to/image.png使用 URLtai tool ocr_recognize --source https://example.com/document.jpg表格提取为 Markdowntai tool ocr_recognize --source /path/to/table.png --type table --output_format markdown发票结构化提取tai tool ocr_recognize --source /path/to/invoice.pdf --type invoice --output_format json指定具体提供商tai tool ocr_recognize --source /path/to/doc.png --provider baiduVLM-OCR 自定义提示词tai tool ocr_recognize --source /path/to/doc.png --provider llm:qwen-ocr --prompt 只提取表格中的金额列PDF 页范围tai tool ocr_recognize --source /path/to/report.pdf --pages 1-5 --output_format markdown参数总览参数类型必填说明sourcestring是待识别的图片或 PDF 文件路径 / URLproviderstring否LLM 连接器 IDllm:xxx或 OCR 设置键baidu/paddleocr/google/azure省略时自动选择typestring否识别类型默认general取值见下方类型表output_formatstring否text默认、json含坐标/字段、markdown结构化modestring否accurate默认质量最佳或standard更快languagestring否语言提示ISO 639-1如en、zh、ja省略时自动检测promptstring否仅 VLM-OCR 的自定义指令追加到系统提示词之后传统 OCR 忽略pagesstring否PDF 页范围如1-5或1,3,7省略时识别全部页extraJSON否提供商特定参数以 JSON 对象形式透传源码层面recognize.go这些参数被依次解析为source / provider / type / output_format / mode / language / prompt七个位置参数加一个extra映射。其中type与output_format会先经过 types.go 中的白名单校验非法值直接返回错误不会进入识别流程。source 支持的输入形式按 recognize_schema.json 的说明source不仅支持普通文件路径和 URL还支持workspace://URI 与attach://URI 两种内部协议分别指向工作区文件与附件资源便于 Agent 在对话上下文中直接引用素材。读取阶段由 recognize.go 调用image.ReadBytes统一完成“取字节 推断 MIME 类型”两步后续所有 handler 都基于同一份字节数据工作。识别类型type从通用文字到证件票据技能文档给出 12 种内置识别类型每种类型都有与其匹配的最佳输出格式类型说明最佳 output_formatgeneral通用文字默认texttable表格提取markdownhandwriting手写文字textdocument文档版式解析markdowninvoice发票增值税发票jsonreceipt收据 / 小票jsonid_card身份证jsonbank_card银行卡jsonlicense营业执照jsonvehicle_license行驶证jsonpassport护照jsonlicense_plate车牌json在源码 types.go 中除了上述内部名称还额外接受 4 个Tao 原生名称general_basic、accurate_basic、idcard、bankcard以便与 Tao OCR 服务对齐。若type为空defaultType 会将其规范为general。类型降级degraded_from这是技能文档强调的重要机制如果所选提供商不支持请求的类型会自动降级为general并在响应元数据中以degraded_from标注原始类型。实现位于 types.go 的degradeTypefunc degradeType(requested string, supported map[string]bool) (actual string, degradedFrom string) { if supported[requested] { return requested, } return general, requested }而VLM-OCR 通过提示词适配支持全部类型——handler_vlm.go 中vlmSupportedTypes将 12 种类型全部标记为支持因此走 LLM 连接器的识别请求几乎不会触发降级。ocr_providers查询可用提供商与能力ocr_providers用于列出当前环境中可用的 OCR 提供商及其支持的识别类型tai tool ocr_providers返回结果是一个提供商列表来源有两类VLM-OCR 模型来自具备ocr能力的 LLM 连接器传统 API 提供商来自 OCR 设置paddleocr/baidu/google/azure。每条记录包含id、name、typevlm或traditionalTao 服务的类型为tao以及supported_types。从实现看providers.golistOCRProviders依次收集LLM 连接器中具备 OCR vision 能力的模型 → Tao OCR 服务 → 四个传统 API 预置项。每个条目的status字段会基于 setting 注册表中的配置状态给出connected/unconfigured/disconnected其中传统 API 提供商的状态取自ocr.providers.key下的enabled与status配置。建议在使用ocr_recognize之前先运行本工具确认哪些提供商可用、支持哪些类型。Provider 解析与选择显式优先、自动兜底技能文档提到 provider 省略时“自动选择”其背后的优先级链在 recognize.go 的resolveProvider中实现显式参数命令行传入的provider优先经classifyProvider归类tool_assignment 设置读取ocr.tool_assignment中为ocr_recognize指定的提供商Tao OCR 服务若 Tao 服务处于connected状态则使用之第一个启用的传统 API依次检查paddleocr、baidu、google、azure的enabled开关第一个具备 OCR 能力的 LLM 连接器通过image.ListProvidersByCapability(ocr)兜底。若全部落空会返回错误提示no OCR provider configured; add one via Settings OCR or specify the provider parameter即需要通过设置界面配置提供商或显式指定provider参数。classifyProviderrecognize.go的判定规则为llm:前缀 → 去除前缀后作为 LLM 连接器tao→ Tao 服务paddleocr/baidu/google/azure→ 传统 API其余字符串则尝试按 LLM 连接器解析并要求其具备 OCR 能力。随后selectHandlerrecognize.go按类型实例化对应处理器LLM →VLMHandlerTao →TaoHandler传统 API 则从设置读取解密后的凭据——PaddleOCR 需要base_url与可选api_key百度需要api_keysecret_keyGoogle 需要api_keyAzure 需要api_keyendpoint。PDF 支持矩阵与多页 PDF 响应各提供商 PDF 支持情况ProviderPDF说明Baidu支持使用pdf_file参数Azure支持Document Intelligence 原生支持PaddleOCR支持pdf参数 fileType0Google不支持Sync API 不支持 PDFVLMllm:不支持视觉模型仅接受图片对于不直接支持 PDF 的提供商文档明确建议改用Baidu、Azure 或 PaddleOCR。源码中对不支持情况的处理是直接返回明确错误例如 handler_vlm.go 在检测到MimeType application/pdf时返回VLM-OCR does not support PDF input; use Baidu, Azure, or PaddleOCRhandler_google.go 同理。多页 PDF自动分页 文件路径摘要多页 PDF 会被自动逐页拆分。工具不会一次性打印全部文本而是返回一个 JSON 摘要包含每页结果对应的临时文件路径{ source: report.pdf, total_pages: 10, pages: 3, results: [ {page: 1, file: .tool-tmp/ocr-a1b2c3d4/page-1.txt, preview: Invoice No: INV-001...}, {page: 2, file: .tool-tmp/ocr-a1b2c3d4/page-2.txt, preview: Invoice No: INV-002...}, {page: 3, file: .tool-tmp/ocr-a1b2c3d4/page-3.txt, preview: Invoice No: INV-003...} ] }需要读取某一页的完整内容时直接使用catcat .tool-tmp/ocr-a1b2c3d4/page-2.txt单页 PDF 和图片则照常返回内联文本不经过文件间接层。注意多页 PDF 的处理结果落在.tool-tmp/临时目录属于一次性的过程产物。三种输出格式的语义output_formattext默认仅返回纯文本最便于 LLM 直接处理output_formatjson返回结构化结果包含text、pages以及存在时的blocks含坐标、置信度和fields键值对字段output_formatmarkdown适用于文档和表格保留版式结构表格转为 Markdown 表格、标题用#标记。格式化逻辑集中在 recognize.go 的formatResponse与formatMarkdownjson输出会携带text/pages并按需附加blocks、fields、metadatamarkdown输出在存在fields时转为键值列表- **字段名**: 值否则直接使用响应中的 Markdown 文本或逐 block 拼装。深入 VLM-OCR提示词工程与 JSON 解析VLM-OCR 走的是“LLM 连接器 视觉模型”路线核心实现位于 handler_vlm.go值得关注三个技术细节系统提示词构建prompt.go 的buildOCRSystemPrompt根据type、output_format、mode、language拼接提示词。每种类型都有专用角色设定typePrompt例如invoice提示“提取发票中的所有关键字段发票号码、日期、金额、税额、购方/销方信息等”accurate模式追加“逐字校对不要遗漏任何文字”standard模式则要求“抓取主要内容简洁输出”。用户自定义的prompt参数会被追加到系统提示词末尾handler_vlm.go。图片编码图片被编码为data:mime;base64,...的 data URI 作为视觉消息内容handler_vlm.go随后与用户消息“请识别图片中的所有文字内容。”一并提交给视觉模型。JSON 结果解析当output_formatjson时模型返回的文本会先剥离json ...代码围栏stripCodeFence再尝试解析出fields、text、blocks含confidence与page解析失败则保留纯文本原样返回handler_vlm.go。传统 OCR API 的底层实现细节Baidu端点映射与 Token 缓存handler_baidu.go 的baiduEndpoint将类型映射到百度云 OCR 端点table→table、handwriting→handwriting、invoice→vat_invoice、receipt→receipt、id_card→idcard、bank_card→bankcard、license→business_license、vehicle_license→vehicle_license、passport→passport、license_plate→license_plate通用类型则按modeaccurate/general与是否需要坐标信息json/markdown输出在accurate/accurate_basic/general/general_basic四个端点间选择。语言参数经baiduLanguage映射为百度的language_type如zh→CHN_ENG、en→ENG、ja→JAP。访问令牌access_token按api_key:secret_key缓存并预留 1 小时安全余量避免每次识别都重新换取handler_baidu.go。响应解析时结构化类型发票、身份证等提取为fields键值对通用类型则逐词块生成blocks含位置框与平均置信度。Azure预置模型与异步轮询handler_azure.go 的azureModelID将类型映射到 Document Intelligence 预置模型invoice→prebuilt-invoice、receipt→prebuilt-receipt、id_card/passport→prebuilt-idDocument、table/document→prebuilt-layout、其余→prebuilt-read。API 版本默认2024-11-30可通过extra.api_version覆盖extra.model_id可强制指定模型。Azure 采用 202 异步响应 Operation-Location轮询模式pollResult每 2 秒轮询一次、最多 60 次约 120 秒超时在succeeded时解析analyzeResult抽取content支持 markdown 格式的outputContentFormat、页数、结构化fields与逐行blocks多边形坐标会按页面宽高归一化。PaddleOCR流水线切换与 fileTypehandler_paddleocr.go 默认使用PP-OCRv5流水线但当类型为table/document或输出为markdown时自动切换为PP-StructureV3版式与表格结构识别能力更强也支持通过extra.pipeline自定义。请求体按 MIME 类型区分PDF 传pdf字段并置fileType0图片传image字段并置fileType1。响应解析同时兼容rec_texts/rec_scores/dt_polys词块数组与 PP-StructureV3 直接返回的markdown字段。Google Cloud Vision特性选择与语言提示handler_google.go 根据mode选择识别特性accurate→DOCUMENT_TEXT_DETECTION文档级质量更高、standard→TEXT_DETECTIONlanguage参数会写入imageContext.languageHints。其supported_types仅覆盖general、document、handwriting三类handler_google.go因此请求invoice、id_card等类型时会被降级为general并在元数据中标注degraded_from。最佳实践速查技能文档末尾给出的使用准则结合源码可以提炼为以下实操要点优先text输出只需要文字内容时使用默认output_formattext对 LLM 处理最友好结构化证件票据用json发票、身份证等结构化类型invoice、receipt、id_card、bank_card、license、vehicle_license、passport、license_plate优先output_formatjson以获取fields键值对文档表格用markdowndocument与table类型用output_formatmarkdown保留版式prompt只对 VLM 生效传统 OCR API 会忽略该参数不要依赖它修正传统 API 的识别行为先ocr_providers后识别调用前先确认可用提供商及其支持类型避免无效请求触发降级PDF 注意提供商选型Google Vision 与 VLM 提供商不支持 PDF需要识别 PDF 时选择 Baidu、Azure 或 PaddleOCR多页 PDF 返回临时文件路径摘要用cat file读取具体页。小结yao-ocr技能通过ocr_recognize与ocr_providers两个工具把“VLM 视觉大模型 四种传统 OCR API”统一封装成一套参数一致、类型规范、自动降级、支持 PDF 分页的识别能力。无论你是想让 Agent 读取发票单据、把表格转成 Markdown还是搭建多提供商 OCR 流水线都可以直接沿用本文的调用方式并结合 tools/ocr 源码理解其内部行为按需通过provider、mode、language、pages、extra等参数做精细化控制。赞分享Agent 框架后端低代码RAG【免费下载链接】yao✨ All your agents and workspaces in one place, on every device you own. Track tasks on a board, accessible from desktop, mobile, browser, or API. Self-hosted.项目地址https://gitcode.com/gh_mirrors/ya/yao点击查看免费下载相关推荐VideoGameBunny-V1-4B与其他多模态模型对比为什么选择这个4B参数的AI模型VideoGameBunny V1 4B与其他多模态模型对比为什么选择这个4B参数的AI模型 在当今多模态AI模型快速发展的时代 VideoGameBunLangchain-Chatchat 文档加载 OCR 模块解析get_ocr 双引擎切换与图片/PDF 文字识别实现Langchain Chatchat 文档加载 OCR 模块解析get_ocr 双引擎切换与图片/PDF 文字识别实现 导读 本文深入剖析 Langchain人工智能大模型RAGAI Agent本地部署后端为什么这款文档转换工具能同时实现高效与精准揭秘Marker的核心优势为什么这款文档转换工具能同时实现高效与精准揭秘Marker的核心优势 在当今信息爆炸的时代处理PDF、图像等文档格式已成为开发者和技术人员的日常挑战。传统的人工智能AI 应用OCR上一篇TranslucentTB透明任务栏启动故障全解决方案从诊断到长效维护下一篇Nextcloud容器化迁移企业级部署架构深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
yao 仓库 OCR 技能全解析：使用 ocr_recognize / ocr_providers 工具实现图片、PDF 与结构化文档识别
Agent 框架后端低代码RAG【免费下载链接】yao✨ All your agents and workspaces in one place, on every device you own. Track tasks on a board, accessible from desktop, mobile, browser, or API. Self-hosted.项目地址https://gitcode.com/gh_mirrors/ya/yao点击查看免费下载导读本文聚焦开源仓库 gh_mirrors/ya/yao 内置的yao-ocr技能tools/skills/yao-ocr/SKILL.md完整讲解其中两个 OCR 工具ocr_recognize与ocr_providers的用法、参数、识别类型与多提供商支持。文章以技能文档为主体结合 tools/ocr 目录下的 Go 源码逐层剖析内部实现读者读完将掌握如何用一条命令从图片/PDF 提取纯文本、表格 Markdown、发票等结构化 JSON如何在 VLM-OCR视觉语言模型与传统 OCR API百度、Google、Azure、PaddleOCR之间选择与切换以及多页 PDF 的结果组织方式。技能概览一个文件、两把“钥匙”yao-ocr技能定义在 tools/skills/yao-ocr/SKILL.md其 Frontmatter 声明name: yao-ocrdescription:将其定位为 OCR 文本识别专家凡是需要从图片或 PDF 中提取文字的场景都应当调用本技能包括发票、收据、身份证、银行卡、营业执照、表格、手写文档以及任意视觉文本内容。技能提供两个工具工具作用ocr_recognize使用 OCR 从图片或 PDF 中提取文字是核心识别入口ocr_providers列出当前可用的 OCR 提供商及其支持的识别类型从源码看两个工具分别对应 recognize.go 中的RecognizeHandler与 providers.go 中的ProvidersHandler它们以tools.ocr_recognize、tools.ocr_providers两个 process 的形式注册供tai tool命令行与 LLM Agent 调用。工具的 JSON Schema 定义在 recognize_schema.json 与 providers_schema.json 中。ocr_recognize核心识别工具的完整用法ocr_recognize从图片或 PDF 提取文字同时支持VLM-OCR视觉语言模型经 LLM 连接器接入和传统 OCR API百度、Google、Azure、PaddleOCR。基础用法纯文本输出tai tool ocr_recognize --source /path/to/image.png使用 URLtai tool ocr_recognize --source https://example.com/document.jpg表格提取为 Markdowntai tool ocr_recognize --source /path/to/table.png --type table --output_format markdown发票结构化提取tai tool ocr_recognize --source /path/to/invoice.pdf --type invoice --output_format json指定具体提供商tai tool ocr_recognize --source /path/to/doc.png --provider baiduVLM-OCR 自定义提示词tai tool ocr_recognize --source /path/to/doc.png --provider llm:qwen-ocr --prompt 只提取表格中的金额列PDF 页范围tai tool ocr_recognize --source /path/to/report.pdf --pages 1-5 --output_format markdown参数总览参数类型必填说明sourcestring是待识别的图片或 PDF 文件路径 / URLproviderstring否LLM 连接器 IDllm:xxx或 OCR 设置键baidu/paddleocr/google/azure省略时自动选择typestring否识别类型默认general取值见下方类型表output_formatstring否text默认、json含坐标/字段、markdown结构化modestring否accurate默认质量最佳或standard更快languagestring否语言提示ISO 639-1如en、zh、ja省略时自动检测promptstring否仅 VLM-OCR 的自定义指令追加到系统提示词之后传统 OCR 忽略pagesstring否PDF 页范围如1-5或1,3,7省略时识别全部页extraJSON否提供商特定参数以 JSON 对象形式透传源码层面recognize.go这些参数被依次解析为source / provider / type / output_format / mode / language / prompt七个位置参数加一个extra映射。其中type与output_format会先经过 types.go 中的白名单校验非法值直接返回错误不会进入识别流程。source 支持的输入形式按 recognize_schema.json 的说明source不仅支持普通文件路径和 URL还支持workspace://URI 与attach://URI 两种内部协议分别指向工作区文件与附件资源便于 Agent 在对话上下文中直接引用素材。读取阶段由 recognize.go 调用image.ReadBytes统一完成“取字节 推断 MIME 类型”两步后续所有 handler 都基于同一份字节数据工作。识别类型type从通用文字到证件票据技能文档给出 12 种内置识别类型每种类型都有与其匹配的最佳输出格式类型说明最佳 output_formatgeneral通用文字默认texttable表格提取markdownhandwriting手写文字textdocument文档版式解析markdowninvoice发票增值税发票jsonreceipt收据 / 小票jsonid_card身份证jsonbank_card银行卡jsonlicense营业执照jsonvehicle_license行驶证jsonpassport护照jsonlicense_plate车牌json在源码 types.go 中除了上述内部名称还额外接受 4 个Tao 原生名称general_basic、accurate_basic、idcard、bankcard以便与 Tao OCR 服务对齐。若type为空defaultType 会将其规范为general。类型降级degraded_from这是技能文档强调的重要机制如果所选提供商不支持请求的类型会自动降级为general并在响应元数据中以degraded_from标注原始类型。实现位于 types.go 的degradeTypefunc degradeType(requested string, supported map[string]bool) (actual string, degradedFrom string) { if supported[requested] { return requested, } return general, requested }而VLM-OCR 通过提示词适配支持全部类型——handler_vlm.go 中vlmSupportedTypes将 12 种类型全部标记为支持因此走 LLM 连接器的识别请求几乎不会触发降级。ocr_providers查询可用提供商与能力ocr_providers用于列出当前环境中可用的 OCR 提供商及其支持的识别类型tai tool ocr_providers返回结果是一个提供商列表来源有两类VLM-OCR 模型来自具备ocr能力的 LLM 连接器传统 API 提供商来自 OCR 设置paddleocr/baidu/google/azure。每条记录包含id、name、typevlm或traditionalTao 服务的类型为tao以及supported_types。从实现看providers.golistOCRProviders依次收集LLM 连接器中具备 OCR vision 能力的模型 → Tao OCR 服务 → 四个传统 API 预置项。每个条目的status字段会基于 setting 注册表中的配置状态给出connected/unconfigured/disconnected其中传统 API 提供商的状态取自ocr.providers.key下的enabled与status配置。建议在使用ocr_recognize之前先运行本工具确认哪些提供商可用、支持哪些类型。Provider 解析与选择显式优先、自动兜底技能文档提到 provider 省略时“自动选择”其背后的优先级链在 recognize.go 的resolveProvider中实现显式参数命令行传入的provider优先经classifyProvider归类tool_assignment 设置读取ocr.tool_assignment中为ocr_recognize指定的提供商Tao OCR 服务若 Tao 服务处于connected状态则使用之第一个启用的传统 API依次检查paddleocr、baidu、google、azure的enabled开关第一个具备 OCR 能力的 LLM 连接器通过image.ListProvidersByCapability(ocr)兜底。若全部落空会返回错误提示no OCR provider configured; add one via Settings OCR or specify the provider parameter即需要通过设置界面配置提供商或显式指定provider参数。classifyProviderrecognize.go的判定规则为llm:前缀 → 去除前缀后作为 LLM 连接器tao→ Tao 服务paddleocr/baidu/google/azure→ 传统 API其余字符串则尝试按 LLM 连接器解析并要求其具备 OCR 能力。随后selectHandlerrecognize.go按类型实例化对应处理器LLM →VLMHandlerTao →TaoHandler传统 API 则从设置读取解密后的凭据——PaddleOCR 需要base_url与可选api_key百度需要api_keysecret_keyGoogle 需要api_keyAzure 需要api_keyendpoint。PDF 支持矩阵与多页 PDF 响应各提供商 PDF 支持情况ProviderPDF说明Baidu支持使用pdf_file参数Azure支持Document Intelligence 原生支持PaddleOCR支持pdf参数 fileType0Google不支持Sync API 不支持 PDFVLMllm:不支持视觉模型仅接受图片对于不直接支持 PDF 的提供商文档明确建议改用Baidu、Azure 或 PaddleOCR。源码中对不支持情况的处理是直接返回明确错误例如 handler_vlm.go 在检测到MimeType application/pdf时返回VLM-OCR does not support PDF input; use Baidu, Azure, or PaddleOCRhandler_google.go 同理。多页 PDF自动分页 文件路径摘要多页 PDF 会被自动逐页拆分。工具不会一次性打印全部文本而是返回一个 JSON 摘要包含每页结果对应的临时文件路径{ source: report.pdf, total_pages: 10, pages: 3, results: [ {page: 1, file: .tool-tmp/ocr-a1b2c3d4/page-1.txt, preview: Invoice No: INV-001...}, {page: 2, file: .tool-tmp/ocr-a1b2c3d4/page-2.txt, preview: Invoice No: INV-002...}, {page: 3, file: .tool-tmp/ocr-a1b2c3d4/page-3.txt, preview: Invoice No: INV-003...} ] }需要读取某一页的完整内容时直接使用catcat .tool-tmp/ocr-a1b2c3d4/page-2.txt单页 PDF 和图片则照常返回内联文本不经过文件间接层。注意多页 PDF 的处理结果落在.tool-tmp/临时目录属于一次性的过程产物。三种输出格式的语义output_formattext默认仅返回纯文本最便于 LLM 直接处理output_formatjson返回结构化结果包含text、pages以及存在时的blocks含坐标、置信度和fields键值对字段output_formatmarkdown适用于文档和表格保留版式结构表格转为 Markdown 表格、标题用#标记。格式化逻辑集中在 recognize.go 的formatResponse与formatMarkdownjson输出会携带text/pages并按需附加blocks、fields、metadatamarkdown输出在存在fields时转为键值列表- **字段名**: 值否则直接使用响应中的 Markdown 文本或逐 block 拼装。深入 VLM-OCR提示词工程与 JSON 解析VLM-OCR 走的是“LLM 连接器 视觉模型”路线核心实现位于 handler_vlm.go值得关注三个技术细节系统提示词构建prompt.go 的buildOCRSystemPrompt根据type、output_format、mode、language拼接提示词。每种类型都有专用角色设定typePrompt例如invoice提示“提取发票中的所有关键字段发票号码、日期、金额、税额、购方/销方信息等”accurate模式追加“逐字校对不要遗漏任何文字”standard模式则要求“抓取主要内容简洁输出”。用户自定义的prompt参数会被追加到系统提示词末尾handler_vlm.go。图片编码图片被编码为data:mime;base64,...的 data URI 作为视觉消息内容handler_vlm.go随后与用户消息“请识别图片中的所有文字内容。”一并提交给视觉模型。JSON 结果解析当output_formatjson时模型返回的文本会先剥离json ...代码围栏stripCodeFence再尝试解析出fields、text、blocks含confidence与page解析失败则保留纯文本原样返回handler_vlm.go。传统 OCR API 的底层实现细节Baidu端点映射与 Token 缓存handler_baidu.go 的baiduEndpoint将类型映射到百度云 OCR 端点table→table、handwriting→handwriting、invoice→vat_invoice、receipt→receipt、id_card→idcard、bank_card→bankcard、license→business_license、vehicle_license→vehicle_license、passport→passport、license_plate→license_plate通用类型则按modeaccurate/general与是否需要坐标信息json/markdown输出在accurate/accurate_basic/general/general_basic四个端点间选择。语言参数经baiduLanguage映射为百度的language_type如zh→CHN_ENG、en→ENG、ja→JAP。访问令牌access_token按api_key:secret_key缓存并预留 1 小时安全余量避免每次识别都重新换取handler_baidu.go。响应解析时结构化类型发票、身份证等提取为fields键值对通用类型则逐词块生成blocks含位置框与平均置信度。Azure预置模型与异步轮询handler_azure.go 的azureModelID将类型映射到 Document Intelligence 预置模型invoice→prebuilt-invoice、receipt→prebuilt-receipt、id_card/passport→prebuilt-idDocument、table/document→prebuilt-layout、其余→prebuilt-read。API 版本默认2024-11-30可通过extra.api_version覆盖extra.model_id可强制指定模型。Azure 采用 202 异步响应 Operation-Location轮询模式pollResult每 2 秒轮询一次、最多 60 次约 120 秒超时在succeeded时解析analyzeResult抽取content支持 markdown 格式的outputContentFormat、页数、结构化fields与逐行blocks多边形坐标会按页面宽高归一化。PaddleOCR流水线切换与 fileTypehandler_paddleocr.go 默认使用PP-OCRv5流水线但当类型为table/document或输出为markdown时自动切换为PP-StructureV3版式与表格结构识别能力更强也支持通过extra.pipeline自定义。请求体按 MIME 类型区分PDF 传pdf字段并置fileType0图片传image字段并置fileType1。响应解析同时兼容rec_texts/rec_scores/dt_polys词块数组与 PP-StructureV3 直接返回的markdown字段。Google Cloud Vision特性选择与语言提示handler_google.go 根据mode选择识别特性accurate→DOCUMENT_TEXT_DETECTION文档级质量更高、standard→TEXT_DETECTIONlanguage参数会写入imageContext.languageHints。其supported_types仅覆盖general、document、handwriting三类handler_google.go因此请求invoice、id_card等类型时会被降级为general并在元数据中标注degraded_from。最佳实践速查技能文档末尾给出的使用准则结合源码可以提炼为以下实操要点优先text输出只需要文字内容时使用默认output_formattext对 LLM 处理最友好结构化证件票据用json发票、身份证等结构化类型invoice、receipt、id_card、bank_card、license、vehicle_license、passport、license_plate优先output_formatjson以获取fields键值对文档表格用markdowndocument与table类型用output_formatmarkdown保留版式prompt只对 VLM 生效传统 OCR API 会忽略该参数不要依赖它修正传统 API 的识别行为先ocr_providers后识别调用前先确认可用提供商及其支持类型避免无效请求触发降级PDF 注意提供商选型Google Vision 与 VLM 提供商不支持 PDF需要识别 PDF 时选择 Baidu、Azure 或 PaddleOCR多页 PDF 返回临时文件路径摘要用cat file读取具体页。小结yao-ocr技能通过ocr_recognize与ocr_providers两个工具把“VLM 视觉大模型 四种传统 OCR API”统一封装成一套参数一致、类型规范、自动降级、支持 PDF 分页的识别能力。无论你是想让 Agent 读取发票单据、把表格转成 Markdown还是搭建多提供商 OCR 流水线都可以直接沿用本文的调用方式并结合 tools/ocr 源码理解其内部行为按需通过provider、mode、language、pages、extra等参数做精细化控制。赞分享Agent 框架后端低代码RAG【免费下载链接】yao✨ All your agents and workspaces in one place, on every device you own. Track tasks on a board, accessible from desktop, mobile, browser, or API. Self-hosted.项目地址https://gitcode.com/gh_mirrors/ya/yao点击查看免费下载相关推荐VideoGameBunny-V1-4B与其他多模态模型对比为什么选择这个4B参数的AI模型VideoGameBunny V1 4B与其他多模态模型对比为什么选择这个4B参数的AI模型 在当今多模态AI模型快速发展的时代 VideoGameBunLangchain-Chatchat 文档加载 OCR 模块解析get_ocr 双引擎切换与图片/PDF 文字识别实现Langchain Chatchat 文档加载 OCR 模块解析get_ocr 双引擎切换与图片/PDF 文字识别实现 导读 本文深入剖析 Langchain人工智能大模型RAGAI Agent本地部署后端为什么这款文档转换工具能同时实现高效与精准揭秘Marker的核心优势为什么这款文档转换工具能同时实现高效与精准揭秘Marker的核心优势 在当今信息爆炸的时代处理PDF、图像等文档格式已成为开发者和技术人员的日常挑战。传统的人工智能AI 应用OCR上一篇TranslucentTB透明任务栏启动故障全解决方案从诊断到长效维护下一篇Nextcloud容器化迁移企业级部署架构深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
