1 分•作者: xvok•大约 1 个月前•原帖
我们解决的问题是组织内部的摩擦和可见性问题。在每一个层级和每一次会议中,你会越来越远离真正了解发生了什么。我们构建了一款工具,让任何人只需点击一个按钮,就能看到项目的实际进展。无需与人工智能争论,也无需依赖甘特图进行推测。只需一个合理的人类解释。 当然,我们一开始不会达到完美。我们专注于做好一件事,让单个项目经理或主管点击“更新”,并以他们期望的方式获取更新。这意味着我们需要“了解”他们的项目。为此,我们正在使用人工智能。 我们并不指望用户在我们的工具中启动项目或调整他们的工作。我们会消化所有信息,并提供状态更新。这意味着我们将工具结构化,以便像项目经理一样理解事物。有些人可能会说这意味着我们无法完美适应他们的项目或程序。对此,我想说:“你并没有你想象中那么独特。”这意味着人工智能的规则和技能会自动调整,将信息分类。我们一开始并不复杂,只有Jira集成和文档上传功能。 当然,仍然有调整的空间。通常这些调整会在人工智能聊天中进行,而在我们这里则通过规则和技能以及结构化提示来实现。但用户对此并不关心。相反,当状态更新返回时,他们会调整一两次。然后,我们在后台调整规则,以便下次应用。因此,我们的准确率起初为80%,但每次使用后都会变得更好。而且,嘿,80%的准确率对于你的项目、你的混乱格式和语气来说已经相当不错了。 那么,最终结果是什么?对最终用户来说,这意味着打开工具,点击“运行”,看到它转动一两秒钟,然后获得一个可以直接使用的状态更新。我们提供的服务是将手动整理文件和项目以获取状态更新的过程,转变为一个简单的“一键获取状态更新”。 简而言之,想象一个这样的世界:当有人问“有什么更新”时,你只需按下一个按钮,他们就会离开,或者给你所需的信息以便继续。这就是我们的目标。 我们的愿景是什么?我的意思是,如果你曾在大公司工作,我们相信在制作状态更新时消除繁琐的艺术中有很大的商机。为此,我们的整体愿景是解决公司中耗时最多的项目管理环节。这意味着一开始的状态更新,但之后还有更多内容(例如项目章程、RACI等)。 想试试我们的Alpha版本吗?请通过[email protected]或[email protected]与我们联系。
1 分•作者: leumon•大约 1 个月前•原帖
看起来PayPal应用现在拒绝在GrapheneOS上运行。我不确定这是否仅仅是因为我启用了PayPal卡进行非接触式NFC支付,但在打开应用时,它会崩溃,并出现以下异常:com.paypal.oslo.app.rasp.RootDetectionSecurityException:安全策略违规:s=root。
1 分•作者: ethanr2000•大约 1 个月前•原帖
我正在寻找一些建议,针对小型技术团队(约3名开发人员)快速开发大型语言模型(LLMs)相关的项目。 和大多数人一样,我们越来越依赖LLMs来生成代码。我们在侧边栏使用Cursor,以保持对应用程序的严格控制和工程质量标准。 然而,我们发现代码审查在开发中成为了一个更紧迫的瓶颈,拉取请求(PR)迅速堆积。生成代码与审查代码所需的时间平衡在过去一年中发生了变化。现在,代码审查所花费的时间相对增加了。 我们尝试过整合像CodeRabbitAI这样的工具,但并没有发现它是解决问题的灵丹妙药。它在报告基本错误和缺失的测试用例方面有用,但通常会忽略在更广泛应用背景下的重要问题。 此外,AI代码审查还错过了代码审查的一个重要目标,即与团队其他成员分享上下文、理解和责任感。 我担心我们最终面临一个严峻的矛盾。我们希望能够比传统的代码审查(即理解)更快地生成新功能,同时仍然希望能够亲自理解所生成的架构和代码。 因此,我在寻找建议。你们尝试过什么有效的方法?在一个比以往任何时候都要更快生成代码的专业工程团队中,需要牺牲什么?
1 分•作者: vsavinov•大约 1 个月前•原帖
在训练大型语言模型时,会面临许多系统挑战以及不同的分片方案。虽然市面上有很多关于扩展大型语言模型(LLMs)的优秀资源(如<a href="https://huggingface.co/spaces/nanotron/ultrascale-playbook" rel="nofollow">https://huggingface.co/spaces/nanotron/ultrascale-playbook</a>或<a href="https://jax-ml.github.io/scaling-book/" rel="nofollow">https://jax-ml.github.io/scaling-book/</a>),但我觉得在可视化不同形式的并行性以及建立对分布式训练运行中重叠和执行顺序的直觉方面仍然存在一些空白。 这个想法是使可视化FSDP(全量梯度分布并行)、Tensor并行、Expert并行和上下文并行变得更加简单,并对此进行推理——你可以拖放计算内核和集合,以基于真实的torchtitan配置创建DDP(分布式数据并行)、TP(张量并行)、FSDP、EP(专家并行)和CP(上下文并行)跟踪。