Dropbox 如何把 Riviera 从文件预览服务升级为 AI 内容处理平台

预计阅读时间：9 分钟

当文件处理只服务于“打开预览”时，系统通常围绕单一请求设计：上传文件、执行转换、返回结果。但 AI 搜索、RAG、电子签名和内容回放需要的是另一种能力——统一处理大量文件格式，支持多种转换，并允许调用方异步获取结构化内容。

Dropbox 正在让 Riviera 承担这个角色：它已经从文件预览服务演进为通用内容处理平台，支持 300 多种文件格式和 100 多种转换能力，每秒处理数十万次转换，并服务于 Search、Replay、Sign 和 Dash 等产品。更重要的是，Riviera 的 API 开始支持异步内容提取，为 AI 和 RAG 工作流提供基础设施。

从“生成预览图”到“统一内容管道”

文件预览只是内容处理的一种结果。现实中的文件可能需要经历以下步骤：

识别格式并读取元数据
从 PDF、演示文稿或文档中提取文本
生成图片、缩略图或其他预览资源
转换文件格式
提取适合搜索或向量化的内容
为签名、回放或分析流程提供中间结果

如果每个产品都单独实现这些逻辑，系统很快会出现重复的格式适配器、不同的错误处理方式，以及难以统一扩展的任务队列。Riviera 的演进方向，是把这些能力收敛到一个平台中：上层产品提交内容处理任务，平台根据输入格式和目标能力完成转换，并通过统一 API 返回结果。

这类平台化设计的关键不只是“支持更多格式”，还包括把转换能力组织成可组合的操作。例如，同一个文件可以先做文本提取，再生成缩略图，或者先提取内容，再进入搜索索引和 RAG 管道。

AI 工作负载为什么更依赖异步 API

传统预览请求往往希望几百毫秒内返回结果；而 AI 内容提取可能涉及大文件、复杂格式、OCR、表格解析或多阶段转换。把这类任务强行塞进同步 HTTP 请求，会带来几个问题：

请求容易超时，客户端需要重复提交。
长任务占用连接和服务线程，影响普通预览流量。
失败重试难以控制，可能造成重复处理。
调用方无法清晰区分“排队中”“处理中”和“处理失败”。

异步接口通常采用三步模型：提交任务、轮询或接收完成通知、读取结果。下面是一个可改造的 API 示例。它使用了常见的任务接口形态；实际接入时，需要把域名、认证方式和字段名替换为你们平台的定义。

# 1. 提交内容提取任务
curl -X POST "https://content.example.com/v1/extractions" \
  -H "Authorization: Bearer $CONTENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source": {
      "object_uri": "s3://knowledge-base/handbook.pdf"
    },
    "operations": [
      {"type": "extract_text"},
      {"type": "extract_metadata"}
    ],
    "output": {
      "format": "json",
      "destination": "s3://knowledge-base/processed/handbook.json"
    },
    "callback_url": "https://rag.example.com/hooks/content-ready"
  }'

# 2. 查询任务状态。把 extraction_id 替换成提交接口返回的 ID
curl "https://content.example.com/v1/extractions/extraction_id" \
  -H "Authorization: Bearer $CONTENT_TOKEN"

典型响应可以设计成这样：

{
  "id": "ext_01JABC123",
  "status": "succeeded",
  "source": "s3://knowledge-base/handbook.pdf",
  "result": {
    "object_uri": "s3://knowledge-base/processed/handbook.json",
    "page_count": 42,
    "text_bytes": 183204
  },
  "error": null
}

对于 RAG 场景，建议让内容处理平台只负责稳定地提取和标准化内容，把切块、嵌入、向量数据库写入放在下游服务。这样可以独立调整 chunk size、重叠长度和 embedding 模型，而不必重新处理原始文件。

高吞吐不等于可以忽略隔离和可观测性

每秒数十万次转换说明平台必须具备很强的吞吐能力，但 AI 工作负载和普通预览流量的特征并不相同。设计类似系统时，可以重点关注以下边界：

队列和优先级

交互式预览通常更看重延迟，批量内容提取更看重吞吐。将任务分为实时队列和后台队列，并设置租户级并发上限，可以避免大规模 RAG 导入拖慢用户打开文件的体验。

幂等和重试

任务 ID 或内容指纹应能参与幂等判断。网络超时后，调用方不应简单地再次创建任务；更稳妥的做法是使用幂等键，或者先查询已有任务状态。重试也应区分临时错误、格式不支持和权限错误。

结果版本

提取结果可能随着解析器、OCR 或转换器升级而变化。结果中最好包含处理器版本、输入文件版本和生成时间，便于定位“同一个文件为什么得到了不同的索引内容”。

安全边界

内容处理平台会接触用户文件，应限制回调地址、校验对象存储权限，并对压缩包、宏文件和超大文件设置资源上限。对于发送给 AI 模型的内容，还需要明确租户隔离、敏感信息处理和日志脱敏策略。

给工程团队的落地路径

如果团队正在构建类似平台，可以按下面的顺序推进：

先统一任务模型：定义输入对象、操作列表、状态、错误和结果位置。
再收敛格式能力：优先覆盖产品实际使用的格式，而不是一开始追求最大的格式清单。
异步化长任务：将大文件、OCR、批量转换和内容提取放入可扩展队列。
对接下游 AI 流程：用稳定的 JSON 或文档结构输出文本、页码、表格和元数据。
建立容量指标：同时观察吞吐、P95/P99 延迟、队列等待时间、失败率和单位文件成本。

Riviera 的案例说明，内容处理平台的价值不再局限于“让文件看起来正确”。当同一套基础设施同时支撑搜索、回放、签名和 AI 提取时，格式解析、转换编排和异步任务管理会成为可复用的产品能力。对于准备接入 RAG 的团队，最值得借鉴的并不是照搬某个接口，而是把内容提取从一次性的脚本，升级为具备队列、幂等、版本和可观测性的长期服务。