返回首页
最新
大多数处理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://news.ycombinator.com/item?id=46296863">https://news.ycombinator.com/item?id=46296863</a>，我想做一些小改动，于是自己制作了一个工具。
这个工具基本上会扫描页面上的所有段落，将5个单词替换为日语罗马字。这些单词的颜色会改变，并且加粗。当你将鼠标悬停在更改的单词上时，会弹出一个小窗口，显示平假名和英文单词。
目前，它的单词列表比较小（111个），所有单词都选择为基础水平，并且（希望）在其上下文中不会造成混淆。
我计划将单词列表扩展到大约1000个，并每周循环更新200个单词，带有一些重叠。
编辑：这是它运行中的截图 - <a href="https://freeimage.host/i/fldb3KB" rel="nofollow">https://freeimage.host/i/fldb3KB</a>
它也正在上传到Firefox插件商店，但这需要一些时间。
嗨，HN，
我是一名C++学生，过去几个月我一直在研究并发数据结构。今天我想分享daking::MPSC_queue，这是一个仅包含头文件的无锁、无限制的MPSC队列，旨在弥合链表灵活性与基于数组的吞吐量之间的差距。
1. 面对挑战：“链表瓶颈”
在传统的MPSC链表队列中，如果多个生产者以高且均匀的频率尝试入队单个元素，结果会导致CAS争用，从而引发严重的缓存行抖动。在这些饱和的均匀负载场景中，吞吐量会达到一个物理“底线”，通常表现不如预分配的环形缓冲区。
2. 针对现实场景的架构解决方案
该设计并不专注于均匀负载下的平均吞吐量，而是针对两个特定的现实挑战：
<i>场景A：非均匀争用（突发韧性）</i>
在许多系统中，生产者大部分时间处于闲置状态，但偶尔会出现突发情况。通过促进一个高速生命周期，使节点块在消费者（回收）-> 全局堆栈 -> 生产者（分配）之间循环，且复杂度严格为O(1)，该队列可以在突发期间迅速建立类似SPSC的性能，峰值可达约161M/s。
<i>场景B：批量争用减少</i>
enqueue_bulk接口允许生产者在私有内存中预先链接整个段。这将N个原子操作的争用减少到单个原子交换。批量越大，争用越低。
3. 隐式分块与资源生命周期
内存管理采用页 -> 块 -> 节点的层级结构，而不是碎片化的分配。
<i>隐式组合</i>：与分块数组不同，节点并不存储在连续的数组中，而是可以自由组合成逻辑“块”。这保持了链表的灵活性，同时获得了块管理的效率。
<i>零成本弹性</i>：无限制的设计消除了在流量高峰期间的背压停滞或数据丢失，堆分配的频率降低到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上看到了一篇关于这个话题的帖子，但现在找不到了，所以我在这里写下我的想法。
最近，我开始了一个用Rust编写的爱好项目，旨在从多个网站收集新闻并为我创建每周摘要。
由于我只是为了好玩，所以我开始开发一个网络爬虫。
然而，一个更简单的选择是使用这些网站的RSS订阅源。因此，我也去寻找它们，但很少有网站提供这个功能。
现在，随着Agentic AI的兴起，RSS似乎变成了一种过时的方式，不再那么必要了。
你怎么看？