Interfaze 新模型架构详尽笔记

先说结论

Interfaze 想解决的是一个很现实的问题：开发者经常把通用 LLM 拿去做本该高度确定、可验证、可规模化的工作，比如复杂 PDF OCR、表格/字段抽取、语音转文字、网页信息补全和 JSON 结构化输出。通用 LLM 能理解语义，但它像人一样会“看错、漏填、编造、格式对但值错”。传统 CNN/DNN 在特定任务上非常稳，却不够灵活。Interfaze 的方案是把两者合在一个共享表示空间里。

它不是要替代 LLM文章明确把定位放在确定性开发任务：OCR、检测、结构化输出、STT、翻译和网页抽取。

它不是单纯 OCR 模型OCR 是第一主场，但系统还会借助目标检测、翻译层、搜索索引和 transformer 语义能力。

它卖的是“准确率乘以成本”基准比较对象主要是 flash/mini 模型和专业工具，而不是最贵的 frontier pro 模型。

1. 文章真正批评的是什么

作者的出发点很清楚：人类擅长理解细微语义和做判断，但不擅长大规模、机械、像素级、字段级的任务。让一个人读 50 页 PDF，把每个词和坐标映射出来，再翻译成中文，结果大概率慢、贵、错漏多。

文章认为很多 Transformer/LLM 在这类任务上也类似。它们非常适合需要人类级判断、解释、推理、创造的任务；但当目标是“每个字段都要对、每个坐标都要准、每次格式都稳定”时，通用 LLM 的弹性反而会成为不确定性来源。

通俗理解：写总结、做推理、解释代码时，你需要一个会思考的人；读发票、抠坐标、转录长音频时，你更需要一台不走神的机器。Interfaze 的论点是：过去我们太常让“会聊天的人”去干“机器该干的活”。

2. DNN/CNN 与 LLM 各自的问题

传统深度神经网络、CNN、CRNN-CTC 这类架构，在 OCR、翻译、GUI 检测等任务上早就存在。它们的优势是任务专用、输出可预测、能给出 bounding box 和 confidence score。文章甚至说，这些专用模型在特定任务上可以显著更准。

但 DNN/CNN 的问题是“不灵活”。它们依赖训练数据，迁移到新任务、新格式、新逻辑时维护成本高。文章举了护照字段抽取的例子：专用模型可以抽出出生日期和坐标，但不能顺手计算年龄，更不能理解业务上下文。

模型类型	强项	短板	适合场景
通用 LLM / Transformer	语义理解、推理、泛化、自然语言交互	值可能错、结构化字段可能幻觉、成本和延迟偏高	复杂问答、代码、开放式分析、需要判断的任务
任务专用 DNN/CNN	稳定、便宜、可输出坐标和置信度	任务边界硬，换任务要重训/维护，不擅长人类级语义	OCR、检测、ASR、GUI/文档解析等确定性任务
Interfaze 声称的混合架构	把专用模块的准确性和 transformer 的灵活性放进共享向量空间	具体内部细节仍是厂商描述，需看独立复现和真实业务测试	高并发、低成本、强准确要求的多模态抽取任务

3. Interfaze 的架构主张

文章把 Interfaze 描述为一种新模型架构：它合并了 DNN/CNN 的专用能力和 omni-transformer 的通用能力。最关键的表述是：这些能力不是简单串联，而是在一个 shared vector space 里协同工作。

专用感知层

面向 OCR、目标检测、GUI 检测、语音转写等任务的 task-specific encoders。

输出：文字、坐标、置信度、时间戳、对象区域等。

共享向量空间 ↔ 让专用模块与 Transformer 互相借力

Omni-Transformer 层

承担跨模态理解、翻译、结构化生成、简单推理、网页信息补全。

输出：schema 对齐的 JSON、解释、翻译、补全字段。

这意味着 OCR 不只是“识字”。在复杂页面里，模型可以同时识别正文、图像区域、图形描述和坐标，再用 transformer 把结果填到 schema 里。文章中的例子显示，同一次请求既返回 schema 化结果，也返回 precontext，里面包含原始 OCR 的行/词级坐标和置信度。

为什么 precontext 重要：普通 LLM 给你一个 JSON，你很难知道它从哪里来的。Interfaze 的设计更像“结果 + 证据层”：上层对象给业务消费，底层 precontext 给开发者审计、回溯、调试。

4. Partial model activation：只启动需要的部分

文章里很重要但容易被忽略的一点，是“partial activation”。使用 <task>ocr</task> 这类系统提示，开发者可以只激活模型中负责某个任务的部分，而不是每次都动用完整权重。

这样做的好处是更快、更便宜、输出更固定、更确定。代价是一次请求只能跑一个任务，输出形态也更固定。它更像调用一个强任务工具，而不是和一个开放式助手对话。

模式	怎么理解	优点	限制
全模型混合模式	OCR、检测、翻译、结构化生成等模块共同参与	能处理复杂多目标任务，一次请求拿到多层结果	成本和延迟相对更高
Partial activation	只激活 OCR 或 STT 等指定任务路径	更快、更便宜、更稳定	一次只能做一种任务，灵活性下降

5. 基准结果怎么读

文章把 Interfaze 与类似价位、类似定位的模型比较，包括 Gemini-3-Flash、Claude-Sonnet-4.6、GPT-5.4-Mini、Grok-4.3，以及若干专业 OCR/ASR 提供商。它没有主打与最贵的 pro-tier 模型在所有任务上硬拼，而是强调低成本、高吞吐的确定性任务。

Benchmark	Interfaze	文章中给出的意义
OCRBench V2	70.7%	复杂 OCR 能力，领先列出的 flash/mini 对照组。
olmOCR	85.7%	长文档/复杂 PDF OCR 是主要用例之一。
RefCOCO	82.1%	视觉定位与引用对象识别，说明不只是文本 OCR。
VoxPopuli WER	2.4%	语音转写错误率，数值越低越好。
Spider 2.0-Lite	52.9%	结构化/数据库查询类能力。
MMMLU	90.9%	多语言理解，文章借此强调英文之外的表现。
MMMU-Pro	71.1%	多模态理解与推理能力。
SOB Value Accuracy	79.5%	结构化输出中“值是否填对”，而不只是 JSON 是否合法。

读基准时要保留的判断：这些数据来自 Interfaze 官方文章和官方 leaderboard。它们很有参考价值，但仍属于厂商发布结果。真正落地前，最好用自己的文档、表格、音频、图片和 schema 做 A/B 测试，尤其要看字段级准确率、长尾格式、失败回退和成本。

6. 为什么 OCR 是第一用例

文章说用户最常拿 Interfaze 做图片和复杂长 PDF 的 OCR。这很合理，因为 OCR 是一个典型的“LLM 能做但不一定该做”的任务：你不仅要读出文字，还要知道文字在哪、图在哪、表在哪、置信度多少、是否能对齐业务字段。

Interfaze 对 OCR 的卖点有三层：

专用 encoder 提高识别准确率，尤其是复杂版式、手写、长 PDF。
目标检测能力可识别图像、插画、GUI 元素和坐标。
Transformer 层能做翻译、摘要、schema 填充和上下文理解。

这比传统“先 OCR，再把文本扔给 LLM”的 pipeline 更紧密。传统 pipeline 容易在步骤之间丢信息：OCR 给了坐标，LLM 只看文本；检测模型知道图在哪，但结构化输出不知道如何引用。Interfaze 的说法是把这些信息放在同一个向量空间和同一响应结构里。

7. 结构化输出：格式对不等于值对

文章对 JSON schema 的批评非常关键：今天很多 LLM 已经能很好地遵守 JSON 格式，但它们经常把字段值填错。对业务系统来说，格式合法只是第一步，真正重要的是值准确。

Interfaze 发布了 SOB，即 Structured Output Benchmark。它的评测方式是：正确答案已经在上下文里，模型要把已有信息填进 JSON，评估谁错得更少、幻觉更少，覆盖文本、图像、音频模态。

通俗例子：如果发票里金额是 1,248.50，模型输出了合法 JSON 但金额写成 1,284.50，工程系统仍然会把它当“成功响应”。SOB 关注的就是这种业务上真正致命的错误。

8. 音频与联网抽取

语音转文字

在 VoxPopuli-Cleaned-AA 上，文章称 Interfaze 的词错误率排第二；速度方面，它声称每秒 compute 可转录 209 秒音频，比 Deepgram Nova-3 快约 1.5 倍，比 Scribe v2 快约 8 倍，比 Gemini-3-Flash 快 11 倍以上。

它还展示了长音频例子：1 小时 35 分钟播客，约 50 秒完成，并返回分块时间戳。这类输出对字幕、会议纪要、音频检索都很有用。

联网抽取

文章还提到 Interfaze 内置 web index，来自多个 SERP index 和自家 crawler。使用方式上仍是 Chat Completions API，但返回结果里会有 object 和 precontext：前者是 schema 化资料，后者是搜索结果证据。

9. 开发者怎么接入

Interfaze 使用 Chat Completions API 标准，因此 OpenAI SDK、Vercel AI SDK、LangChain 等能直接兼容。核心变化是把 base URL 指向：

https://api.interfaze.ai/v1

模型名是 interfaze-beta。文章示例里最值得注意的不是 SDK 代码，而是响应结构：业务结果放在 schema object 中，底层 OCR、搜索、语音转写的原始证据放在 precontext 中。

返回层	用途	开发价值
`object`	符合 schema 的最终结果	直接进入业务系统、数据库、自动化流程
`precontext`	原始 OCR / 搜索 / STT 等底层结果	审计、追踪、调试、置信度判断、二次校验
`<task>`	指定 partial activation 的任务类型	降低成本和延迟，获得更确定的固定输出

10. 我的整理：适合谁，不适合谁

很适合发票、合同、身份证件、长 PDF、扫描件、表格、语音转写、网页资料补全、需要字段级准确率的批处理。

谨慎使用需要复杂创造、长链推理、产品策略、代码架构设计、开放式研究的任务。这类任务仍适合强 generalist 模型。

必须自测如果业务错误成本高，不能只看官方分数。要用自己的样本测字段准确率、漏检率、置信度阈值、失败样式和成本。

如果用一句话概括这篇文章：Interfaze 试图把 AI 产品从“通用聊天模型调用”拉回到“可预测的工程系统”。它承认 transformer 的理解力很强，但也认为确定性任务需要专用感知模块、证据层、部分激活和更严格的值准确率评估。

落地前要追问的问题

官方 benchmark 是否能在你的文档类型、语言、扫描质量和 schema 上复现？
precontext 的置信度是否足够用于自动放行，还是需要人工复核阈值？
partial activation 的固定输出是否满足你的业务，还是仍需要多任务混合模式？
长 PDF、表格跨页、图片内嵌文字、手写、多语言混排的失败样式是什么？
与现有 OCR + LLM pipeline 相比，总成本、延迟、可观测性是否真的更好？
厂商模型、benchmark 和 API 仍处 beta 阶段时，是否有回退方案？

来源

本文为对 Interfaze 官方博客正文反复阅读后的中文整理，不复刻原文和长代码，只保留必要指标、架构解释和落地判断。