原贴链接

此为外部链接https://www.timescale.com/blog/stop-over-engineering-ai-apps，无实际可翻译内容

讨论总结

该讨论围绕“Stop over - engineering AI apps: just use Postgres”这一主题展开。评论者从Postgres是否能同时充当noSQL和向量数据库、框架效率、不同数据库在本地和大规模场景下的适用性、对Postgres的支持与反对态度等多方面进行了探讨，其中也夹杂着一些有趣的荒诞表达以及对职场现象的感慨。

主要观点

  1. 👍 Postgres可能具备同时充当noSQL和向量数据库的功能
    • 支持理由：Pgai在做所有的嵌入工作，是Postgres之上的一个扩展，pgvector不计算嵌入只是索引并实现快速近似最近邻搜索方法等相关讨论
    • 反对声音：无
  2. 🔥 全能框架可能存在效率低下的问题
    • 正方观点：框架要支持的用例越多，就越不可能针对单个用例进行完全优化
    • 反方观点：无
  3. 💡 使用Postgres像是过度工程化
    • 正方观点：自己实现LM时可以根据自身需求创建文件格式而不用外包存储等
    • 反方观点：有意义的应用除AI功能外本身就需要类似Postgres的东西，还不如用于嵌入以避免栈的进一步复杂化等
  4. 👍 认可停止过度设计AI应用而使用Postgres这一发展
    • 支持理由：大家花大量时间发明新的AI工具和方法或重复劳动，而现在经典工具可扩展与AI集成
    • 反对声音：无
  5. 🔥 本地环境下不需要花哨的向量存储，sqlite + sqlite - vec适用于本地情况
    • 正方观点：简洁且适用于本地情况
    • 反方观点：无

金句与有趣评论

  1. “😂 I got ebola from postgres”
    • 亮点：以一种荒诞的方式将Postgres与埃博拉联系起来，非常奇特且无厘头。
  2. “🤔 The more different use cases a framework needs to support, the less likely it’s fully optimized for any single one of them.”
    • 亮点：阐述了框架效率低下的一个关键原因。
  3. “👀 Works great until you need to scale it.”
    • 亮点：提出了Postgres在扩展规模方面可能存在问题的观点。
  4. “😎 Heh, I like this development a lot.”
    • 亮点：表达对停止过度设计AI应用而使用Postgres这一发展的喜爱。
  5. “🤨 And now, the classic tools just extend to integrate with AI instead.”
    • 亮点：指出经典工具可与AI集成这一积极方面。

情感分析

总体情感倾向较为多元，既有对使用Postgres的赞同，也有反对的声音。主要分歧点在于Postgres是否适合用于AI应用、是否存在过度工程化以及在不同场景下的适用性等。可能的原因是评论者们基于各自不同的技术背景、项目经验和需求来发表观点。

趋势与预测

  • 新兴话题：MariaDB将拥有的向量数据类型可能比pgvector更快。
  • 潜在影响：如果MariaDB的向量数据类型性能更优，可能会影响数据库在AI应用开发中的选型。

详细内容：

标题：关于是否应使用 Postgres 而非过度工程化 AI 应用的热门讨论

在 Reddit 上，一篇题为“Stop over-engineering AI apps: just use Postgres”的帖子引发了广泛关注。该帖子获得了众多点赞和大量评论。主要讨论方向围绕着 Postgres 在 AI 应用中的作用以及其与其他数据库和框架的比较。

讨论焦点与观点分析： 有人提出 Postgres 能否同时充当 NoSQL 和向量数据库的功能，并对其 AI 后端代码的位置产生疑问。还有人认为 Pgai 负责所有的嵌入操作，一切都在数据库内部。有人分享了自己之前对 Postgres 的类似想法。也有人指出 pgvector 并不计算嵌入，只是对其进行索引和实现快速近似最近邻搜索方法。 有人认为通用框架可能效率不高这一观点很有趣。通常，框架虽比手动实现功能不佳的情况更有效，但不如手动实现功能良好的效率高。有人分享了使用 Postgres 进行相关开发的经历，称其进展顺利。 对于是否使用 Postgres 存在不同看法。有人觉得使用 Postgres 是过度工程化，有人则反驳称并非如此。有人称自己实现了小型语言模型并自行处理存储，还举例说明不用 Postgres 处理用户登录的情况。但也有人指出，若不使用关系型数据库服务器，在用户规模扩大时可能会遇到问题，如数据一致性在电源故障时的维护。 有人提到 Langchain 代码存在问题，认为 Postgres 在处理大量数据时向量搜索时间较慢，而 NoSQL 数据库如 Cosmos DB 也在增加相关功能。但也有人反驳称并非如此，并推荐了 pgvectorscale。

总的来说，这场讨论呈现出观点的多样性和复杂性，有人支持使用 Postgres，有人则持保留态度。而关于数据库的选择和应用，仍需要根据具体需求和场景来权衡。