最新

大多数处理 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 进行了完善，但经过了彻底的人工检查。

昨天读了这篇文章之后，<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46296863">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46296863</a>，<p>我想稍微改动一下，于是就自己动手做了一个。<p>基本上，它会扫描页面上的所有段落，用日语罗马音替换其中的 5 个单词。这些单词的颜色会改变并加粗显示。当鼠标悬停在被替换的单词上时，会弹出一个小窗口，显示平假名和英文单词。<p>目前，它有一个小型的单词列表（111 个），所有单词都经过挑选，属于基础级别，并且（希望）在上下文中不会引起混淆。<p>我计划将单词列表扩展到大约 1000 个，并且每周循环使用 200 个单词，并有一定的重叠。<p>编辑：一个运行截图 - <a href="https:&#x2F;&#x2F;freeimage.host&#x2F;i&#x2F;fldb3KB" rel="nofollow">https:&#x2F;&#x2F;freeimage.host&#x2F;i&#x2F;fldb3KB</a><p>它也正在上传到 Firefox 插件商店，但需要一段时间。

Hi HN， 我是一名 C++ 学生，在过去的几个月里，我一直沉迷于并发数据结构的研究。现在我分享 daking::MPSC_queue，这是一个仅头文件、无锁、无界 MPSC 队列，旨在弥合链表灵活性和基于数组的吞吐量之间的差距。 1. 直面挑战："链表瓶颈" 在传统的 MPSC 链表队列中，如果多个生产者尝试以高且均匀的频率入队单个元素，则由此产生的 CAS 争用会导致严重的缓存行弹跳。在这些饱和的均匀负载场景中，吞吐量会达到一个物理“下限”，其性能通常不如预先分配的环形缓冲区。 2. 针对现实世界场景的架构解决方案 该设计没有侧重于均匀负载下的平均吞吐量，而是针对两个特定的现实世界挑战： * 场景 A：非均匀争用（突发弹性） 在许多系统中，生产者通常处于空闲状态，但偶尔会发生突发。通过促进一个高速生命周期，其中节点块从消费者（回收）-> 全局堆栈 -> 生产者（分配）循环，且复杂度严格为 O(1)，该队列可以在突发期间快速建立类似 SPSC 的性能，峰值约为 1.61 亿/秒。 * 场景 B：批量争用减少 enqueue\_bulk 接口允许生产者在私有内存中预先链接整个段。这减少了从 N 个原子操作到单个原子交换的争用。批次越大，争用越低。 3. 隐式分块和资源生命周期 内存管理通过 Page -> Chunk -> Node 层次结构进行，而不是碎片化的分配。 * 隐式组合：与分块数组不同，节点不是存储在连续的数组中，而是自由地组合成逻辑“块”。这保持了链表的灵活性，同时获得了块的管理效率。 * 零成本弹性：无界设计消除了流量高峰期间的背压停顿或数据丢失，堆分配频率降低到 log(N)。 4. 工程严谨性 * 安全性：已通过 ThreadSanitizer (TSAN) 和 ASAN 的全面审核。 * 类型安全：支持不可默认构造的类型；noexcept 自动推导。 * 轻量级：零依赖，仅头文件，并与 C++17/20 兼容。 关于基准测试的说明： 为了完全透明，我已将其与 moodycamel::ConcurrentQueue 进行了基准测试。在高度均匀、小粒度的争用场景中，我们的实现略慢。但是，daking::MPSC\_queue 在非均匀突发和批量传输场景中提供了 3-4 倍的性能提升，其中“零成本弹性”和减少争用是主要目标。 我很想听听您对这个存储库的看法！ GitHub：[https://github.com/dakingffo/MPSC\_queue](https://github.com/dakingffo/MPSC_queue)

我最近在 HN 上读到过一篇关于这个话题的帖子，但现在找不到了，所以在这里写下我的想法。<p>最近，我开始了一个用 Rust 编写的业余项目，它从几个网站收集新闻，并为我创建一个每周摘要。<p>因为我只是为了好玩才做的，所以我开始开发一个抓取器。<p>然而，一个更简单的选择是使用网站的 RSS 订阅。因此，我也去找了它们，但很少有网站提供 RSS 订阅。<p>现在，随着 Agentic AI 的出现，RSS 订阅似乎已经过时，不再需要了。<p>你觉得呢？