24小时热榜

行业正越来越多地朝着复杂的自主代理循环和反馈链发展。这显然伴随着显著的延迟、不确定性、低准确性和成本。我希望听到那些走向相反方向的工程师的意见。在你们的产品生命周期的哪个阶段，你们决定代理方法并不是适合这个工作的工具？是什么具体的失效模式（可靠性、成本、延迟、可维护性）促使你们用更确定性的系统/管道替代代理循环？

嗨，HN， 我是Nazim，Koinju.io的创始人，我想在这里分享一个我们最近开启的探索性选项：通过SQL提供对我们数据库的访问，该数据库包含所有加密货币市场数据。虽然REST可以直接检索数据，但我们越来越认为，针对统一的加密市场数据层提供SQL访问对于分析工作可能会很有价值，尤其是在大语言模型（LLM）的背景下。 这一想法部分受到OpenBB首席执行官Didier Lopes最近关于金融公司拥有金融工作基础设施的文章的启发，特别是工作流执行和AI推理发生的运行时环境。 大多数数据API是为那些已经知道自己想要什么的软件设计的。调用一个端点，获取JSON，解析它，然后在其他地方进行计算。这种模型运作良好，并且仍然有效。但我不确定它是否适合LLM驱动的工作流，尤其是在大数据的情况下。 语言模型可以调用API、读取JSON或编写Python代码来实现（Claude代码可以强制输出JSON）。但这并不意味着模型在处理、重塑、连接、聚合、验证或推理大型结构化数据集时是高效的，尤其是通过标记化的行。在小规模时，它适合上下文限制；但在大规模时，它变得复杂，小细节可能会悄然消失，仿佛它们是异常值。 因此，我们正在测试的论点是： 对于大数据集，面向AI的基本操作应该从“返回JSON”切换为“在数据集上执行一个有限的、可检查的操作”，这是一个你可以计划、重放甚至精确追踪的操作。在这种情况下，LLM承担了规划者/控制者的角色。它应该能够检查模式、理解约束、表达操作、检查限制甚至抽象语法树（AST），通过执行层运行计算，然后对紧凑的类型化结果进行推理。 因此，SQL是我们在这一层的当前尝试。 这其实并不新颖，也不是什么神奇的“AI原生”。但它是明确的、可检查的、可组合的，并且接近数据可执行。REST在简单检索时仍然有意义。但对于大型市场数据集的分析问题，JSON分页似乎不是合适的工作单位。 这里还有一个治理问题：在金融行业，许多公司不希望他们的整个工作流迁移到供应商的黑箱接口。这似乎是合理的。内部上下文、权限、模型政策、审计日志和决策工作流当然应该存在于公司的环境中。但这并不一定意味着每个外部数据集在提出任何问题之前都应该被本地复制。 也许更好的边界是： - 公司拥有工作流和推理运行时 - 数据提供者暴露一个受控的执行表面 - LLM发出有限的操作 - 查询引擎执行实际计算 - 结果返回 我对从事类似工作的人提供的任何反馈都很感兴趣，包括市场数据、量化研究、分析等。我试图回答的问题是： - 今天，LLM处理大数据的正确接口是什么？ - 模型应该在原始数据、JSON、模式、SQL、类型化工具、语义层或其他什么上操作？ - 客户拥有的运行时与提供方数据执行之间的边界应该在哪里？ 当调用者可能是一个代理时，查询限制、成本预览、干运行、权限和审计日志应该如何运作？ 我并不只是寻求验证。如果答案是“不要创造一个新的AI类别；只需提供干净的数据、稳定的模式、SQL、文档和可预测的限制”，那也是有用的。