最新

大多数处理 PDF 或图像的产品都在默默地重建同样的东西：一个拼凑起来的“路由器”，它选择调用哪个 OCR/视觉 API，规范化响应，并祈祷月底的账单是合理的。 DocsRouter 作为一款产品，就是这一层：一个稳定的 API，与多个 OCR 引擎和视觉 LLM 对话，允许您根据成本/质量/延迟来路由每个文档，并为您提供规范化的输出（文本、表格、字段），这样您的应用程序就不必关心使用了哪个提供商。 它适用于那些使用文档进行严肃工作的团队：发票/收据、合同、工资单、医疗/管理表格、物流文档等，他们要么被困在“我们几年前选择的 OCR”上，要么被新视觉模型的快速变化所淹没。 目前，您将获得一个 REST API、简单的 SDK（即将推出）、一些可插拔的后端（经典 OCR + 较新的视觉模型）、一些基本的路由策略，以及一个游乐场，您可以在其中上传文档并并排比较输出。 我希望从 HN 获得关于两件事的反馈： 1 - 如果您已经同时使用多个 OCR/视觉提供商，您的自制路由器是什么样的，您需要什么才能信任外部路由器？ 2 - 您更喜欢这个，还是直接使用 LLM/OCR 提供商，并有可能经常更换提供商？ 演示和文档在这里：[https://docsrouter.com](https://docsrouter.com)

在不同组织构建机器学习系统后，我将编写的一些实用工具整合到一个库中。 这个库可以实现的功能： * 在对象存储上保存（和检索）模型检查点（可选使用内容可寻址命名方案） * 从对象存储中将数据集增量加载到 Pytorch 中，使用本地磁盘缓存 * 将训练指标存储到 SQLite 中 设计原则： * “云端简单，软件智能” - 我更倾向于使用对象存储和容器运行时等通用服务，而不是类似框架的抽象（例如托管的 MLFlow 或类似服务） * 以最直接的方式扩展 Lightning * 让用户通过对现有模型代码进行最少的更改来组装轻量级的 MLOps 流程 欢迎提出任何问题并提供反馈！ 该库使用 Sonnet 进行了完善，但经过了彻底的人工检查。