Algorithm

本周选择的算法题是：Maximum Value of an Ordered Triplet II。

class Solution:
    def maximumTripletValue(self, nums: List[int]) -> int:
        n = len(nums)
        leftMax = [0] * n
        rightMax = [0] * n
        for i in range(1, n):
            leftMax[i] = max(leftMax[i - 1], nums[i - 1])
            rightMax[n - 1 - i] = max(rightMax[n - i], nums[n - i])
        res = 0
        for j in range(1, n - 1):
            res = max(res, (leftMax[j] - nums[j]) * rightMax[j])
        return res

还有空间复杂度 O(1) 的实现方式：

class Solution:
    def maximumTripletValue(self, nums: List[int]) -> int:
        n = len(nums)
        res, imax, dmax = 0, 0, 0
        for k in range(n):
            res = max(res, dmax * nums[k])
            dmax = max(dmax, imax - nums[k])
            imax = max(imax, nums[k])
        return res

很巧妙的实现~

Review

How to Do Great Work

Paul Graham 的文章，如何做出伟大的工作，Paul Graham 同时也是《黑客与画家》的作者。

他总结了一套适用于各领域的工作方法，涵盖工作选择、执行、心态以及与他人协作等多方面内容，总结为 6 个关键点：

要选择自己有天赋、感兴趣且有发展空间的工作，这样才能保持好奇心，坚持下去
要自我研究项目，不要让 “工作” 只是别人告诉你要做什么，伟大的工作往往是自己挖掘出来的
保持乐观，乐观主义者更可能做出伟大的工作，而如果把自己当成受害者看待，那就相反了
培养创新思维，关注那些看似疯狂但有潜力的想法，选择有创新性的问题进行研究
向优秀的人学习、交流合作，从不同领域汲取灵感，这样才能持续提升自己的能力和信心
挫折是工作的一部分，没什么大不了的，重要的是提高自己的能量，并且与具备相同能量的人一起工作

Tip

给 RocketMQ 交了学费：

如果期望在同个实例下订阅不同的 topic，那么要把 group 也区分开。

简单聊聊对从 Dify 到 Rill-Flow：大模型应用平台的进化之路的看法，先总结一下：

一家公司选用了 dify 作为大模型应用平台，dify 界面美观、操作方便、没什么商业限制，确实是很不错的选择。但 dify（这里要强调下是低版本）也有自身的问题：

流程开始后无法人工干预
错误处理能力有限
多任务并发的性能问题

主要是这三个，然后围绕这些问题提出了一个系统性的解决方案：通过引入高性能工作流引擎 Rill-Flow，大幅提高 dify 的性能和可靠性。

dify 的改造成本也并不会很高，两个工作：

开发一个 DSL 转换器将 dify 的 DSL 描述文件转换为 Rill-Flow 的，在具体流程上，先基于 dify 前端界面操作，得到原始的 DSL，再转换为 Rill-Flow 的格式，并由 Rill-Flow 负责调度、执行
调度不在由 dify 负责，而是在 dify API 上增加执行单个节点的接口，使 Rill-Flow 能直接调度 dify 执行任务，改造成本低、无侵入性

不过，我不太看好这个方案，关于上面提到的三个痛点：

流程开始后无法人工干预；需要人工干预的流程可以通过自定义节点来实现，dify 对自定义节点要完成什么没有任何限制，比如实现一个人工审核节点对 LLM 返回的内容进行 review；将需要等待外部事件或特定时间再推进的流程，可以拆解为不同的 workflow，workflow 之间可以互相调用，也是一种不用依赖研发资源的解决方案
错误处理能力有限；自 dify 0.14.0 版本起，已经有了一个方便、灵活的错误处理策略：

多任务并发的性能问题；这可能属于资源利用率的问题，如果整个分布式系统处于饱和，那么无论是否引入 Rill-Flow 都不太会带来性能提升，而要提高资源利用率，也并非只有 Rill-Flow 这一种解法，在集群根据系统负载做横向伸缩也行

此外，方案缺少实现细节、测试环境说明、详细指标，轻易跟风 ROI 太低，再关注关注；还有，从产品角度来看，工作流引擎作为一个产品功能，在实际业务场景中，用户期望它具备良好的错误处理能力，能够跳过非必须的失败节点、自动发起重试等，以保证工作流的顺利执行，虽然 dify 旧版本没有，但需求是存在的，这种问题被解决只是时间问题，不要和官方正面竞争。

Algorithm

Review

Tip

Share