一周热榜

我开源了一个包含5个合成银行和信用卡对账单PDF的数据集，旨在测试提取/解析的准确性。每个PDF都使用了来自不同国家的虚构银行，并采用了现实的格式。 我一直在构建一个银行对账单转换器（Bankstatemently），并不断发现不同银行的边缘案例。在某个时刻，我开始将这些情况归类为“特性”，目前我已经记录了36个挑战，并且还在不断增加（例如：跨年度的日期没有年份、信用卡费用以正数而非负数显示、日期隐藏在描述文本中等）。 真实的银行数据是私密的，因此没有共享的数据集可以用来测试解析器。一旦我收集了这些特性，我意识到可以利用它们重建故意包含这些挑战的对账单，以便更多人使用。 此外，还有一个免费的评估API：提交您的解析JSON并获取字段级的准确性评分。真实数据存储在服务器端，但这并不一定能防止过拟合。 我希望能收到关于缺失的边缘案例的反馈。我计划让接下来的10个对账单变得更具挑战性（扫描的PDF、多货币、多表格、佛教纪元日期）。 您可以在这里浏览所有特性及其真实世界的示例： [https://bankstatemently.com/benchmark/challenges](https://bankstatemently.com/benchmark/challenges)

我在使用大型语言模型（LLMs）时遇到的主要问题，以及最阻碍我进一步采用它们的原因，是代理无法记住相关上下文。<p>几年前，大家都在使用RAG、嵌入、数据库等技术来增强模型的能力。而现在，能够访问本地Markdown和记忆文件的模型（如OpenClaw）似乎在性能上明显优于这些依赖grep和简单UNIX工具的数据库。<p>这是LLMs在扩展时固有的问题吗？对于大多数人来说，Obsidian的效果真的好得多吗？有没有人发现有什么东西实际上能超越Markdown？<p>目前，我在采用这些技术时的主要瓶颈似乎是记忆和持久的长期上下文，而不是模型的质量或可靠性。<p>我很好奇是否有任何技术或扩展指标可以用来预测这一领域的未来发展方向。

Tril将代码库中的每个函数转换为简单的英文描述，然后运行并测试它们——使用大型语言模型（LLM）作为解释器，而不是运行时环境。 这个概念是：编程语言的存在是因为机器无法理解人类的意图。而大型语言模型可以理解。那么，如果完全去掉代码，仅仅描述每个函数应该做什么，会发生什么呢？ 这个工具逐个替换函数，在每次替换后运行测试套件以确认没有出现错误，并输出一个.md文件。然后，`tril run`会启动一个HTTP服务器，将每个函数的英文描述发送给Claude，并返回结果。 在一个单位转换器（JavaScript）和一个625行的Python命令行工具上进行了测试——测试通过，结果精确到小数点后六位（幸运的是）。 这主要是一个思想实验：任何代码都能变成简单的自然语言吗？它仍然能正常工作吗？让我们来看看吧！ npm: npx @sliday/tril convert URL GitHub: [https://github.com/sliday/tril](https://github.com/sliday/tril)

我们从2006年10月以来每天收集了前三条HN（Hacker News）故事（总计约21,000条），对这些故事进行了主题聚类，并可视化了主题随时间的变化情况。<p>您可以放大查看任何时间段——一些模式出人意料地清晰（例如，人工智能超越创业文化成为HN的热门话题，加密货币的兴起与衰落，以及因COVID疫情导致的远程工作的激增）。<p>欢迎随时询问有关方法论的问题。

我对这种炒作曾经翻了个白眼，但实际上，<i>阅读</i>这方面的内容和<i>体验</i>它是完全不同的。如果你有任何旧的代码库，试试看，你可能会感到惊讶。 我不确定对于复杂的遗留企业系统，长期的“*90% 生产力*”的说法是否可信，但对于模板、库、构建工具和重构来说，收益是巨大的。那些耗时且令人紧张的工作大部分都得到了处理。 一开始你会像鹰一样仔细检查每一个差异，期待它会破坏东西，但老实说，很快你会发现大多数情况下这并不是必要的。你只需保持IDE开启，将“分析代码”的输出反馈给它。在Java中，告诉它“<i>添加checkstyle，运行mvn verify并修复</i>”的效果很好，你甚至可以去喝杯咖啡，而不是与linter警告作斗争。 理论上，剩下的只是<i>逻辑</i>和<i>想法</i>。当架构真正变得复杂时，我们将看看这一点是否成立。但目前，让它分支、创建模板并编写简单的测试，同时你只需在规格上进行迭代，效果出奇地好。只有在写下规格用普通英语太麻烦时，你才会编写源代码。 这提出了一个真正的问题：如果你的竞争对手Y刚刚解雇了90%的开发人员以节省成本，你会盲目跟随吗？还是会保留你的团队，利用这个巨大的杠杆，以一个远远更好的产品将Y彻底超越？