24小时热榜

大家好，你们可能还记得我，曾写过《精益创业》和《创业之道》这两本书。 自从我写下《精益创业》已经过去了十五年，在这段时间里，我见证了许多事情。在大型企业和小型初创公司、非政府组织和政府机构，几乎在你能想到的每个行业中。 我帮助了很多人创造了许多令人惊叹的公司，但我也看到过许多可能出错的方式。我们的行业中存在一种黑暗面，我们常常不愿意谈论。 我不断看到一些优秀的公司逐渐偏离了它们创立时的使命。这并不是因为有人某天醒来决定要做坏事，而是因为它们所依赖的结构慢慢将它们拉向了那个方向。我称这种拉力为“财务引力”。 我们都经历过看到自己喜爱或钦佩的公司被扭曲和破坏到面目全非的过程；直到它们变成了曾经的壳，甚至更糟。我想要理解其中的原因。我也想知道我们所有人可以做些什么来阻止这种情况的发生。 我新书《不可腐蚀》是我试图解释塑造组织的无形力量，以及少数几家公司（如好市多、巴塔哥尼亚和诺和诺德）是如何成功地构建以抵抗引力并在数十年甚至数百年中蓬勃发展的。 在这个过程中，我创立了长期股票交易所，与杰里米·霍华德共同创办了一个名为Answer.AI的人工智能研发实验室，并帮助了一些知名公司的治理（是的，包括Anthropic）。 我不会假装我已经完全弄明白了这一切，但我可能在“好公司为何变坏”这个问题上花费了比健康更久的时间。欢迎随时问我任何问题！

我们今天开源了14个组件和示例，用于PDF、DOCX和XLSX查看器，以及边界框引用、文件上传、电子签名等功能。这些组件采用MIT许可证，完全可定制。 <p>演示视频请点击这里：<a href="https://share.extend.ai/kRmSGKRF">https://share.extend.ai/kRmSGKRF</a></p> 当我们开始时，尝试了所有能找到的文件查看器和文档组件库。不幸的是，没有一个具备我们想要的所有功能（和精致度），所以我们最终为<a href="https://extend.ai/">https://extend.ai/</a>构建了自己的解决方案。最初这只是为了内部使用，但由于有足够多的客户不断询问，我们决定将其开源。 <p>这个项目对于构建文档处理代理、实时用户文档接收流程或各种内部工具非常有用。</p> 我们天真地认为这是一个已解决的问题。结果发现，制作能够大规模运行的PDF/XLSX/DOCX查看器并非易事……我们自己在Extend使用和维护这个项目，因此在处理每天数百万页的过程中修复了许多边缘案例。我们希望借助我们的资源和社区支持，随着时间的推移，它会不断变得更好。

我曾在一些大型公司工作过（包括FAANG），发现这些公司似乎通过表面化的行为来追求赞誉。大多数团队成员都在做一些管理层认为很 impressive 的无用工作，而少数几个明星员工则真正推动团队朝着目标前进。 与此同时，许多经理的日程安排几乎都是与团队中的开发人员进行一对一的会议，这显然对团队的价值提升很有限。 还有其他人注意到这一点吗？我不确定是否有一个词来形容这种现象，但与一群把自己装扮成工程师的企业办公室员工一起工作，确实让人感到有些士气低落。

请访问以下链接观看视频： [https://www.youtube.com/watch?v=K5LAFEjTlBA](https://www.youtube.com/watch?v=K5LAFEjTlBA)

嗨，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>非常感谢！欢迎评论和反馈！