请记住，亚马逊可以进行A/B测试功能，因此错误可能仅在某个特定功能正在对您进行A/B测试时出现。
<p>2025年9月17日 5.18.5</p>
* 据我所记，没有严重的错误。
<p>2025年11月5日 5.18.6：</p>
* 移除了在书中打开完整词典的功能，仅保留预览。“打开词典”曾经位于“在Goodreads上分享”的位置。
* 移除了专用书签栏。
* 德语词典错误：
* “我举个例子，标记了德语单词dahertrampelten。这是一个带有前缀daher的可分动词。在5.18.6之前，我的Kindle可以识别这个词，并给出整个单词的定义。5.18.6之后，它只显示前缀的定义。”
* “如果有人真的需要知道dahertrampeln的意思，告诉他daher的定义是[没用的]。”
<p>日语词典错误：</p>
* “词典试图默认查找高亮文本中最短的[日语]单词，而不是最长的。”
* 如果这个[日语]问题出现在英语中，表现为：“你试图高亮‘lighthouses’。它高亮了‘light’并显示定义。”
<p>2025年12月10日 5.19.0-5.19.1：</p>
* Kindle Scribe 2025独占固件，但未来的固件会继承这些问题。
* 由于某个域名在常见的默认黑名单上，使用自定义DNS的用户在睡眠状态下会导致电池耗尽，因为会无限请求重试。
<p>2026年2月17日 5.19.2+：</p>
* 破坏了AZW3/KFX书籍中的嵌入字体，其中某些文本部分指定了明确的字体，通常用于标题和小标题。现在这些文本使用通用字体渲染。[在5.19.4中修复]
* azw3书籍缺少页码[在5.19.3中修复]
* azw3书籍的阅读进度追踪器损坏[在5.19.3中修复]
* azw3书籍翻页延迟[在5.19.3中修复]
* azw3漫画/漫画的阅读进度追踪器损坏[在5.19.4中部分修复]
* azw3漫画/漫画翻页延迟[在5.19.4中部分修复]
* azw3漫画/漫画在Aa菜单中缺少所有布局选项。
* mobi/azw3漫画/漫画添加了巨大的边距[在5.19.3中修复]
<p>2026年3月27日 5.19.3</p>
* 在几天后撤回，包含5.19.3.0.1中的所有更改。
<p>2026年4月7日 5.19.3.0.1：</p>
* 排除了Kindle Basic 11代2022和Paperwhite 11代，以便它们不再获得任何修复。
* 修复了之前提到的各种普通书籍azw3问题，包括缺少页码、阅读进度追踪器、翻页延迟。
* 修复了之前提到的漫画边距问题。
* azw3漫画/漫画在双页横向模式下现在显示页面在错误的一侧[在5.19.4中修复]。
<p>2026年4月24日：</p>
* 如果Kindle Basic 11代2022和Paperwhite 11代停留在5.19.2版本，连接WiFi后将修复azw3漫画的边距问题，他们必须关闭导致该错误的功能的A/B测试（新UI）。
<p>2026年5月7日 5.19.4：</p>
* 在几天后撤回，包含5.19.4.0.1中的所有更改。
<p>2026年5月21日 5.19.4.0.1：</p>
* 仅适用于Colorsoft、Paperwhite 12代和Scribe 2022。
* 对于azw3书籍，完全刷新选项不再有效，包括普通可重排和漫画。这可能在5.19.3中损坏。
* 嵌入字体已修复！！！！！！
* 修复了azw3漫画横向顺序问题。
* 部分修复了azw3漫画的阅读进度追踪器。之前完全不工作，现在可以使用，但在结束时会卡在100%，而不是标记为已读。不过其他百分比如25%和50%现在可以正常工作。
* azw3漫画翻页速度大幅提高，稍微慢于5.18.5，但比5.19.2快得多。
* azw3漫画虚拟面板仍然缺失。
<p>2026年5月20日：</p>
* 亚马逊停止通过WiFi下载Kindle商店内容，并注册第1至第5代Kindle。
* 去年已停止通过USB下载Kindle商店内容。
<p>2026年6月2日：</p>
* 5.19.4.0.1已为Scribe 2025/2024和Basic 2024发布。
Kindle Basic 2022 11代和Paperwhite 5（11代）用户停留在5.19.2版本。
用户可以通过Kindle设置 > 帮助 > 联系我们 > 电子邮件选项提交正式投诉。
返回首页
最新
我将简短扼要地总结一下，我们已经见证了大型语言模型（LLM）使用的几个发展阶段。
1. 聊天
2. 自动补全
3. 使用RAG嵌入知识
4. LLM调用工具（CLI或MCP）
5. 执行任务的代理型LLM
你认为下一步或下一次迭代会是什么？
我的理论是，到2026年底，我们将获得更多量化和高效的模型。我希望我们能有一些围绕工具的小型模型（我称之为领域代理），它们只提供答案，而不增加上下文的复杂性。
也就是说，领域代理给调用代理提供香肠，但并不解释香肠是如何制作的。
我很好奇你的理论是什么，但我认为我们可能需要对LLM与工具等结合的架构进行全面的重新思考。
嗨，HN，距离我们推出 HelixDB（<a href="https://news.ycombinator.com/item?id=43975423">https://news.ycombinator.com/item?id=43975423</a>）已经过去一年多了，这是我和一位朋友在大学时开始的项目。它是一个基于对象存储的在线事务处理（OLTP）图数据库，具有原生向量搜索和全文搜索（FTS）功能。
<p>为什么选择图数据库、向量和 FTS？图数据库为数据提供了一种自然的认知模型，向量则允许对图中的实体和关系进行语义理解，而 FTS 则提供了更具体的过滤功能。许多 AI 驱动的应用尝试通过将多个不相连的系统拼接在一起，来结合所有这些功能，但即便如此，仍然没有原生的方法来执行跨所有系统的连接或查询。你仍然需要在应用层处理这些逻辑。
<p>Helix 最初是作为一个图数据库开始的，但在尝试构建 AI 记忆系统后，我们转向了混合图/向量的方法，这使我们深入研究了 GraphRAG 和 HybridRAG 的问题，这需要分别使用图数据库和向量数据库。
<p>我们知道，在产品开发的每个阶段，扩展性都会是一个挑战，然而我们过去一年的初步重点是通过本地部署来验证产品，这仅仅是为了在单个节点上运行。扩展图数据库仍然是一个困难且昂贵的问题，我们必须在后续解决。
<p>其他图数据库解决扩展性的一些常见方法是通过在分布式机器上复制整个数据集（每个节点的成本极高）或通过分片数据。
<p>分片数据库是有效且经济的，然而，图数据并不像关系数据库那样具有明确的分区。例如，分片关系数据库涉及到拆分表。当涉及到图数据库时，边缘可以跨越任何分区，在遍历节点时跨多个机器跳跃是低效且计算成本高的。
<p>为了实现高可用性和更好的吞吐量，复制图数据库会大幅增加数据库的运营成本，并且仍然有垂直扩展的限制。我们所需的工作负载需要存储大量的代理数据，而在任何时刻只需使用其中的一小部分。因此，与其将整个数据放在内存中，我们可以将所有数据存储在对象存储中，并在需要时获取所需的部分。
<p>代理从更好的上下文中受益，这通过更多和更好的数据（更多关系等）来实现。通过使用 S3 作为持久化/数据层，图的大小或关系的数量没有<i>限制</i>，我们可以通过水平扩展节点并在每个节点上缓存图的相关子集来扩展以满足吞吐量和请求。这样，你可以获得“热”数据的极低延迟，以及来自冷存储（S3）的写入约 100 毫秒的 p99 和读取约 50 毫秒的延迟。此外，你还可以享受超便宜的存储。
<p>HelixDB 当前支持的工作负载包括：
- 需要搜索和遍历的海量数据（TB级）
- 为公司提供经济实惠的图存储，解决图数据成本瓶颈
- 整合多个数据库，使 AI 代理能够自主决策，帮助公司变得更加自主
- AI 记忆
- 公司大脑
<p>我们目前正在开发自己的通用 AI 记忆层，它将以 HelixDB 为基础，并完全开源。此外，我们正在完成向量搜索的预过滤功能，这将允许你根据图中的关系、元数据和子图进行预过滤。最后，GA 云将在接下来的几周内上线。
<p>如果你想在本地运行 Helix（无论是磁盘上还是内存中），可以在我们的 GitHub 上找到更多信息（<a href="https://github.com/HelixDB/helix-db" rel="nofollow">https://github.com/HelixDB/helix-db</a>）或通过我们的文档（<a href="https://docs.helix-db.com/database/local-development">https://docs.helix-db.com/database/local-development</a>）。如果你有兴趣开始使用我们的分布式云，请发送电子邮件至 founders@helix-db.com。
<p>非常感谢！欢迎评论和反馈！
Chirpper是邀请制的。当你为某人担保时，他们将加入你的信任链（TrustChain）。他们的行为会影响你的信任等级（TrustRank），并向上影响整个链条。没有管理员。责任是通过架构设计来实现的，而不是依赖政策。你可以使用化名，但不能不负责任。欢迎在评论中深入讨论机制。
你好，HN，
我叫Riccardo，我为独立开发者创建了AuthAI。
这个想法非常简单：让最终用户连接他们的ChatGPT/Grok/Copilot账户，并通过他们的AI订阅来路由AI请求。
这使得许多新的酷点子得以实现，尽管商业模式/单元经济并不总是合理。
流程很简单：
用户点击“用AI登录”，选择他们的服务提供商，并在提供商的网站上授权设备。
令牌使用每个用户的AES-256-GCM加密密钥进行加密，该密钥不会存储在服务器端，只存在于用户的JWT会话中。整个安全模型可以在网站或GitHub上找到。
这里有一个演示：
[https://demo.authai.io](https://demo.authai.io)
从开发者的角度来看，目标是尽可能接近OpenAI SDK：
```ts
const openai = new OpenAI({
apiKey: jwt,
baseURL: "https://relay.authai.io/v1",
defaultHeaders: {
"x-authai-secret": process.env.AUTH_AI_SECRET,
},
});
```
此外，还有一个用于处理连接流程的React SDK。
* 它是MIT许可的，完全开源，提供了托管的中继服务，但整个堆栈可以自我托管。
GitHub仓库：
[https://github.com/authai-io/authai](https://github.com/authai-io/authai)
你会在你的生成应用和副项目中使用这样的东西吗？我还可以添加什么？
鉴于人工智能的使用日益增加，我的经验是，团队成员的工作节奏非常快，产生了大量的变更，以至于几乎不可能对所有内容进行审查。有时我甚至无法跟上自己使用大型语言模型（LLMs）生成的代码。诚然，我可以放慢这一切的速度。当以下情况之一成立时，我确实会这样做：
1. 这是我想要理解的新领域
2. 我对当前领域的代理不够信任
3. 这是极其复杂且细致的工作
依赖于“神谕”（能够提供一个真实依据，以便LLMs可以对其实现进行检查的东西）让我在跳过审查时感到更加自信，也让我安心。广泛的测试和正式验证似乎将取代代码审查。
代码审查还提供了指导、设计反馈和共享所有权。那么，指导的方向在哪里转移了呢？人们是否仍然有时间进行设计审查？
开源AI辅助的1000多行的拉取请求（PR）是另一个完全不同的挑战。我在这里的最佳技巧是提取PR中的关键思想，并自己重新实现一遍。