为什么90%的AI初创公司死于推理成本：Blackwell B200与FP4如何重新定义算力ROI
过去五年，我看了超过两百个AI创业项目的BP。其中90%的失败，不是因为算法不够惊艳，而是因为算力成本烧钱速度超过了业务变现速度。当一个客户要求用GPT-5.5级别的模型做7×24小时的实时客服，却只愿意按H100的旧价格买单时，这个项目注定是死局。 英伟达这次没有在PPT上画大饼，Bla…
大语言模型
OpenAI o1 暴力破解数学与代码（2024）：我为什么在架构里砍掉 GPT-4o 的计算资源
最近在重构团队内部的代码生成流水线时，我面临一个经典的架构决策难题：是继续沿用 GPT-4o 这种高吞吐、低延迟的“即插即用”方案，还是引入 OpenAI o1 系列（o1-preview 和 o1-mini）这种引入了“推理”机制的模型？ 作为干了十年的后端架构师，我习惯先看底层原理，再看上层表现…
我在Amazon Q上跑了一遍RAG流程，发现它简化了ACL 2024那篇论文里的重排序步骤，但查询延迟少了70%
我们组最近接了个云原生运维知识库的项目，要用Amazon Q把积压了五年的内部文档、Runbook、架构决策记录全接起来，让开发用自然语言查询就能拿到可执行的代码片段。我一开始以为这就是个标准RAG（检索增强生成）管道，最多套个漂亮的聊天界面，但真正动手把企业数据源配上去、和CodeWhispere…
我照着普林斯顿SWE‑Agent论文搭了一条需求即交付管线，但在生成验收标准上卡了两个月——LLM在第287次构建时给我上了一课
今年初我翻到普林斯顿那篇SWE‑Agent论文的时候，脑子里冒出一个很自然的念头：既然LLM agent能自动解决GitHub issue，那能不能反过来，从issue出发自动生成验收标准，再用验收标准驱动代码生成和CI流水线，把“需求即交付”真正跑通？实验室有个内部项目刚好要重构一个微服务，需求方…
需求变更率直降40%：我让LLM参与用户故事拆分的180天实录
需求变更率直降40%不是靠运气。我用了半年时间把大语言模型焊死在需求分析阶段，设计了一条从原始需求到可测试场景的提示链，并加入AI评委机制专职检测歧义与矛盾。评审会时间虽多出30%，但测试阶段的需求缺陷密度从3.2暴跌至0.8，每提前发现一个致命矛盾，就挡掉了一次可能发生在凌晨的生产事故。这条路没有银弹，但比起在代码库上反复做开胸手术，我宁愿多花些时间维护prompt。