最新

我了解出箱模式、限流模式、变更数据捕获（CDC）、幂等消费者、主/从架构、电路断路器、缓存、分片、分区等许多概念。我对它们的理解足以通过技术面试，能够回答相关问题，也足以在已经实施了这些解决方案的环境中工作，只需了解它们的存在。 但我从未在生产环境中实施过这样的解决方案。尽管我有超过十年的经验，当然在个人项目中也曾尝试过这些主题，但我从未将自己的解决方案部署到生产环境中。 在非常小的公司中，这些模式通常不需要。而在大中型公司中，它们通常已经被实施了。 你呢？

嘿，HN！<p>我是一名长期读者。最近，我花了超过五个月的时间来现代化我自2008年以来一直在维护的一个旧网站：<a href="https://whatthemovie.com" rel="nofollow">https://whatthemovie.com</a>。这是一个简单的游戏，玩家可以上传电影截图，其他玩家需要根据图片猜出电影的标题。这些图片都是来自电影场景的，而不是宣传材料或其他东西。<p>我们有70,000名用户（但大多数用户活跃于2008-2010年，所以现在大部分不活跃），在过去的18年里，我们的用户上传了超过600,000张图片。数据库中还有大约30,000部电影。<p>多亏了大型语言模型（LLMs），我得以现代化这个处于糟糕状态的技术栈（Rails 4.2，Ruby 2.4，杂乱的代码，Prototype.js，以及直接在HTML中的CSS代码等）。进行所有的重构和现代化工作非常耗费精力，但最终我对结果感到满意。<p>我们现在还推出了“每日挑战”（类似于Wordle或framed.wtf），每天发布一个新的挑战，玩家需要通过不同类型的挑战（如放大、剪辑、聚焦等）找到电影的标题。这完全不需要账户：<a href="https://whatthemovie.com/daily" rel="nofollow">https://whatthemovie.com/daily</a><p>我们还在“保险库”中举办“封闭比赛”：基本上我们组织临时比赛，所有上传的截图必须符合特定标准（一个年代、一个类型、“情感”、“城市”、“手机”等）：<a href="https://whatthemovie.com/vault" rel="nofollow">https://whatthemovie.com/vault</a><p>技术栈很简单：在Hetzner的裸金属服务器上，图片存储在AWS S3上，使用Docker Compose管理大约10个微服务（Redis、MariaDB、Python中的AI侧车、Opensearch等）。有一个小的Ansible剧本来配置机器。使用New Relic监控性能，使用Rollbar跟踪错误。我主要使用Claude模型来完成工作，有时也会使用其他模型来质疑Claude模型的原始评估，或者尝试寻找其他模型未能找到的内容。<p>感谢您的关注，欢迎随时提问！<p>Yann

几天前偶然发现了一些非常有趣的东西，觉得这可能对其他使用Claude代码运行动态工作流的人也很有趣。工作流脚本本身是JavaScript。Claude代码了解这种格式，可以制作一个工具来组合工作流，而不是每次都通过大型语言模型（LLM）进行处理。 我成功实现了这个功能，并经过一些调整后，工作流执行和监控的令牌消耗减少到了之前的约20%，显著加快了速度（我们的大多数工作流以前需要5-6小时，现在只需20-40分钟）。 我们让Claude分析了过去几周的工作流（工作流执行记录在磁盘上，位于~/.claude/projects），并识别出它们之间的共性。结果发现实际上有三种工作流步骤，以各种临时方式完成。 - 代码变更代理/实施者/工作者 - 这个代理从计划中获取任务并执行；这样的代理可以并行运行。 - 检查门代理 - 这个代理试图弄清楚实施者代理做了什么，并评估不应并行执行的内容。 - 最终检查，负责部署、运行API测试等。 此外，Claude还可以从标准“代理”（来自./claude/agents）中组合工作流，而不是每次都通过LLM为工作流代理编写提示；因此我让它找出共性和变异性，它编写了三个代理脚本，后来我们将其减少到两个： - workflow-worker - 获取计划的一部分，并仅限于对其自身计划/文件边界的写入和测试权限，不修复其他人可能正在做的事情，绝对不运行整个测试套件。 - workflow-gate - 从一组并行工作流代理获取结果，基于git中发生的变化运行串行验证（例如，如果任何www文件发生变化，则运行web测试；如果任何后端文件发生变化，则运行API测试等）。这以前每次都由LLM自定义编写，但我们将其移动到一个包含两个目标的makefile中，因此make workflow-serial-gate检查git树并对更改运行测试，make workflow-final-gate对所有内容运行清理测试，部署到暂存环境，运行部署后测试。 由于变异性移入了makefile，这两个代理定义变成了标准的100行markdown，LLM不再需要每次编写。 接下来，由于代理定义已标准化，我们让Claude实际编写了一个工具，读取包含步骤和依赖关系的计划文件，并直接编写工作流JavaScript。以前，复杂计划的返回时间通常需要10分钟，而现在只需一秒钟。 由于工作流代理提示是静态的且只编写一次，因此不会消耗令牌。由于整个测试运行的编排在makefile中，基于git变更，因此在这方面也不会消耗令牌。由于工作者代理获取计划和步骤编号，因此不会消耗令牌告诉它们该做什么（除了它们读取特定步骤，这个是不可避免的）。令牌几乎只在创建计划、狭义实施任务和上下文修复问题时消耗。 当命名代理作为工作流的一部分运行时，传递给预工具使用钩子的上下文包括代理的名称（例如，workflow-worker，workflow-gate），因此我们能够显著限制它们。例如，workflow-worker不允许运行make或整个测试套件，并发送消息将该任务委派给门代理。 最终结果令人惊叹，工作流运行得更快，消耗的令牌也远少于之前。Claude几乎自己编写了整个过程，因此如果你运行动态工作流，我绝对推荐这个实验。如果有人感兴趣，我很乐意提供更多信息。

我想提高印地语检索的质量，特别是对于较长的文档（因为目前的架构并不支持较长的上下文长度），并且我很好奇我能将一台4090推到什么程度，哈哈 :) 因此，我从零开始训练了一个以印地语为主的ModernBERT模型： - 1.88亿参数 - 约285亿印地语标记 - 8192标记的上下文，这是首批支持8K上下文的印地语编码器之一（直接提升了检索能力，编码器模型正是为此而用） 使用1× RTX 4090（24GB）进行了约5天的训练。 经过DPR微调后，它在我评估的印地语检索基准上达到了当前的最佳水平： - mMARCO印地语：0.2825 nDCG@10 - MLDR印地语：0.2635 nDCG@10 MLDR的结果尤其有趣，因为它评估的是长文档检索，在这种情况下，8K上下文窗口可以真正发挥作用。 它还达到了： - 印地语命名实体识别（NER）：0.8001 F1 - MASSIVE印地语意图识别：0.4731 Macro-F1 模型和评估的详细信息： - [模型链接](https://huggingface.co/kkkamur07/hindi-modernbert) - [GitHub链接](https://github.com/kkkamur07/indic-modernBERT) 我的目标是将这一成果扩展到许多低资源语言，我非常感激能够获得反馈和合作机会 ;) 以便我能进一步改进这个模型。