最新

我将简短地介绍一下大型语言模型（LLM）使用方式的演变过程，我们已经看到了几个阶段： 1. 聊天 2. 自动补全 3. 使用 RAG（检索增强生成）嵌入知识 4. LLM 的工具调用（CLI 或 MCP） 5. 能够执行任务的智能体式 LLM 您认为下一步或下一个迭代会是什么？ 我的理论是，到 2026 年底，我们将拥有更量化、更高效的模型。我希望届时会出现围绕工具的迷你模型（我称之为领域智能体），它们可以直接提供答案，而不会过度增加上下文。 也就是说，领域智能体直接提供“香肠”，而无需解释“香肠是如何制作的”。 我很想听听您的理论，但我认为我们可能需要对 LLM 与工具结合的架构进行全面重新思考。

各位 HN 的朋友们，距离我们发布 HelixDB (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43975423">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43975423</a>) 已经一年多了。这是一个我和朋友在大学时启动的项目。它是一个基于对象存储的 OLTP 图数据库，支持原生向量搜索和全文搜索 (FTS)。 为什么选择图、向量和 FTS？图数据库为数据提供了自然的认知模型，向量能够语义化理解图中的实体和关系，而 FTS 则提供了更精确的过滤。许多由 AI 驱动的应用试图通过拼接多个不相关的系统来整合这些功能，但即便如此，也没有原生方法可以执行跨越所有系统的连接或查询。你仍然需要在应用层面处理这些逻辑。 Helix 最初是一个图数据库，但在尝试构建一个 AI 记忆系统后，我们转向了混合图/向量方法。这让我们深入研究了 GraphRAG 和 HybridRAG，在这种情况下，我们需要独立的图数据库和向量数据库。 我们知道可扩展性将是我们产品开发各个阶段的挑战。然而，过去一年的初步重点是证明产品的可行性，通过本地部署，并且最初只打算在单个节点上运行。图数据库的可扩展性仍然是一个我们以后必须解决的困难且昂贵的问题。 其他图数据库解决可扩展性的一些常见方法是将整个数据集复制到分布式机器上（每个节点的成本极高），或者对数据进行分片。 数据库分片是有效且经济的，然而，图数据不像关系型数据库那样有明确的分区。例如，关系型数据库的分片涉及拆分表。对于图数据库来说，边可以跨越任何分区，而在遍历节点时跨越多个机器效率低下且计算成本高昂。 为了高可用性和更好的吞吐量而复制图数据库会极大地增加数据库的运营成本，并且在垂直扩展方面仍然有限制。我们使用的场景需要存储大量的代理数据，而这些数据中只有一小部分在任何时候都需要。因此，我们不需要将所有数据都放在内存中，而是可以将所有数据存储在对象存储中，并在需要时获取所需的数据块。 代理可以从更好的上下文受益，而这可以通过更多更好的数据（更多的关系等）来实现。通过使用 S3 作为持久化/数据层，图的大小或关系的数量**没有限制**，我们可以通过水平扩展节点和在每个节点上缓存相关的图子集来扩展吞吐量和请求。这样，你可以获得对“热”数据的极低延迟，以及从冷存储（S3）写入的 p99 约 100 毫秒，读取约 50 毫秒。此外，你还可以获得极其廉价的存储的好处。 HelixDB 目前支持的工作负载： - 大量数据（TB 级别），代理需要搜索和遍历 - 为图数据成本成为瓶颈的公司提供经济实惠的图存储 - 整合多个数据库，使 AI 代理能够自主管理公司，帮助它们变得更加自主。 - AI 记忆 - 公司大脑 我们目前正在开发自己的通用 AI 记忆层，该层将使用 HelixDB 作为底层，并完全开源。此外，我们正在完成向量搜索的预过滤功能，该功能允许你根据图中的关系、元数据和子图进行预过滤。最后，GA 云将在未来几周内可用。 如果你想在本地运行 Helix（在磁盘上或内存中），可以在我们的 GitHub (<a href="https:&#x2F;&#x2F;github.com&#x2F;HelixDB&#x2F;helix-db" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;HelixDB&#x2F;helix-db</a>) 或我们的文档 (<a href="https:&#x2F;&#x2F;docs.helix-db.com&#x2F;database&#x2F;local-development">https:&#x2F;&#x2F;docs.helix-db.com&#x2F;database&#x2F;local-development</a>) 中找到更多信息。如果你有兴趣开始使用我们的分布式云，请发送邮件至 founders@helix-db.com。 非常感谢！欢迎评论和反馈！

Chirpper 是一个邀请制平台。当你担保某人加入时，他们就会加入你的信任链（TrustChain）。他们的行为会影响你的信任等级（TrustRank），并沿着血缘关系向上蔓延。没有版主。问责制是架构性的，而非基于政策的。你可以使用化名，但不能逃避责任。我很乐意在评论区详细介绍其机制。

你好 HN， 我是 Riccardo，我为独立开发者创建了 AuthAI。 这个想法很简单：让终端用户连接他们的 ChatGPT/Grok/Copilot 账户，并通过他们的 AI 订阅来路由 AI 请求。 这催生了许多新的酷想法，而这些想法的商业模式/单位经济效益并非总是合算的。 流程很简单： 用户点击“使用 AI 登录”，选择他们的提供商，然后在提供商的网站上授权设备。 令牌使用每个用户的 AES-256-GCM 加密密钥进行加密，该密钥不会存储在服务器端，并且仅存在于用户的 JWT 会话中。完整的安全模型可以在网站/GitHub 上找到。 这是一个演示： 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 你会将这样的东西用于你生成的应用程序和副项目吗？我还能添加什么？

随着人工智能（AI）使用的增加，我的经验是，团队成员的开发速度非常快，产生了大量的代码变更，以至于几乎不可能全部审查。有时我甚至跟不上自己使用大型语言模型（LLMs）生成代码的速度。诚然，我可以放慢速度。当出现以下情况时，我确实会这样做： 1. 这是一个我想了解的新领域 2. 我不信任该代理在当前领域的能力 3. 这是一项极其复杂且细致的工作 依赖“神谕”（即能够提供大型语言模型可以对照检查其实现的基本事实）可以极大地增强信心，并在跳过代码审查时让我感到安心。广泛的测试和形式化验证似乎将取代代码审查。 代码审查也提供了指导、设计反馈和共同所有权。指导的去向何方？人们是否仍有时间进行设计审查？ 开源 AI 辅助的千行以上拉取请求（PR）是另一回事。我在这里最好的方法是提取 PR 的关键思想，然后自己重新实现。

各位朋友，你们可能还记得我写的《精益创业》和《创业维艰》这两本书。<p>自从我写了《精益创业》已经过去了十五年，在这段时间里，我看到了很多事情。无论是在大公司还是初创企业，在非政府组织还是政府机构，几乎所有你能想到的行业里。<p>我帮助了很多人创建了许多了不起的公司，但我也看到了太多事情会出错。我们的行业中存在着一种我们常常避而不谈的黑暗面。<p>我一直看到优秀的公司偏离了它们创立的初衷。不是因为有人某天醒来决定变坏，而是因为它们赖以生存的结构慢慢将它们推向了那个方向。我称这种拉力为“财务引力”。<p>我们都曾有过这样的经历：看着一家我们喜爱或钦佩的公司被扭曲、损坏到面目全非；直到它只剩下空壳，甚至更糟。我想理解为什么会这样。我想知道我们所有人能做些什么来阻止这种情况发生。<p>我的新书《不腐蚀》（Incorruptible）试图解释塑造组织的无形力量，以及少数几家公司（如好市多、巴塔哥尼亚和诺和诺德）是如何成功地构建自身以抵抗这种引力，并在此基础上蓬勃发展数十年甚至数百年。<p>在此期间，我创立了长期股票交易所（Long-Term Stock Exchange），与杰里米·霍华德（Jeremy Howard）共同创办了名为Answer.AI的人工智能研发实验室，并协助多家知名公司（是的，包括Anthropic）完善了公司治理。<p>我不会假装自己已经完全明白了这一切，但我可能花了比健康所允许的更多的时间来研究“为什么好公司会变坏”这个问题。有什么都可以问我！