一周热榜

这是一个小型社交实验：每个用户一生只能发布一条帖子（永久，不可删除或重发）。发布后，你将解锁动态，查看其他人选择了什么。

大多数抵押贷款处理延迟并不是由于风险造成的，而是由于手动工作流程造成的。 我们一直在开发SimplAI，这是一个专为银行和金融服务设计的人工智能驱动系统，首先应用于抵押贷款操作。 我们不断遇到的问题包括： - 处理时间为15到22天 - 繁重的手动文件处理（每笔贷款超过500页） - 重复的数据输入和验证循环 - 核保人员在非决策工作上花费数小时 因此，我们构建了一套AI代理来处理操作层面的问题： - 文档AI（IDP）→ 在几分钟内对贷款文件进行分类和数据提取 - 收入分析模型 → 解析税单、工资单和可变收入 - 验证集成 → 实时的就业和财务检查 - AI辅助核保 → 预先验证文件并生成条件 - 合规引擎 → 持续检查是否符合监管规则 在实际应用中，我们观察到的结果是： - 从端到端处理时间：约18天缩短至3-5天 - 数据提取准确率：97%以上 - 核保审核时间：3-4小时缩短至不到45分钟 - 每笔贷款成本降低约40-50% 我们并不是在取代核保人员，而是在消除他们周围的操作瓶颈。 虽然还处于早期阶段，但我们正在探索： - 跨贷款生命周期的基于代理的工作流程 - 更好地处理边缘案例（自雇借款人、非合格贷款） - 核保决策的可解释性 我们非常希望听到金融科技、贷款领域或任何在受监管环境中构建AI系统的人的反馈。

嗨，HN， 我开发了 hanoi-cli，这是一个小型命令行工具，用于分析 Kubernetes 节点上 Pod 的分布情况，并建议更好的放置方案。 这个想法来源于一个反复出现的问题：即使请求/限制设置得当，集群往往还是会出现不平衡的情况。有些节点负载过重，而其他节点则未得到充分利用。 期待大家的反馈。

嗨，HN， 我创建了OpsOrch，因为运营工作分散在太多工具中。 事件可能在PagerDuty中，日志在Datadog中，指标在Prometheus中，而运行手册则在其他地方。每个系统都有自己的API和数据模型，因此跨工具的工作流程通常变成了粘合代码。 OpsOrch是我尝试标准化这一切的结果。 它为事件、日志、指标、警报、服务和运行手册等定义了一个通用的架构，然后使用适配器将不同的提供者连接到一个接口后面。 目标很简单：客户可以请求： - 影响某个服务的事件 - 相关的日志和指标 - 关联的运行手册上下文 我特别希望听到关于这个抽象是否真的有用的反馈，或者在实际应用中是否变得过于通用。 欢迎提问关于架构、适配器模型和权衡的内容。