Jeff Dean 离职前最后一次对话这两天在技术社区讨论声量不小。先声明这篇不写八卦离职的时间线和对话原文我也无法逐一核实真正值得聊的是这段对话里反复出现的两个判断一个是他低估了 AI 的演进速度另一个是创业者如果继续做“重复造基座模型”这件事路会越来越窄。也许有人觉得这是大佬的客套话但从工程角度看这两个判断其实对应一套很具体的技术选型逻辑。模型底座还在快速升级创业者如果押错了层前面投的钱、囤的卡、攒的算法团队很容易变成沉没成本。反过来如果押对了场景多数业务链路并不需要自己训练大模型真正吃功夫的地方在数据、评测、效果调优和交付稳定性。这篇文章我会把对话背后能落地的内容拆开讲先看这次讨论释放了哪些技术信号再给一份 AI 创业技术选型速览接着分析算力、成本、数据、合规这四道关口最后给出 API 调用、RAG、Agent 编排、批量任务、本地部署和效果评估的具体做法。就算你不创业这套思路也适合用来衡量“下一个 AI 项目要不要做”。1. 这次访谈释放的几个核心信号脱离具体场景去复述“我低估了 AI”没有意义对技术团队来说这句话能拆成几个可感知的趋势。第一基座模型的能力天花板还在抬升。很多团队在产品规划时默认“当前模型的能力就是半年后的能力”但事实往往不是这样。指令跟随、多模态理解、长上下文、推理能力几乎每隔几个月就有一次明显变化。这意味着产品架构要留出替换模型的余地不要让业务逻辑和某个模型版本强耦合。第二模型调用和部署成本在快速下降但成本依然是商业模式能否跑通的关键变量。对话里提到看清创业者的生路本质上是在说与其在模型层和巨头拼资源不如在具体场景里把“模型能力业务数据交付体验”做成一个完整闭环。单点能力很容易被追平数据和场景不会被轻易追平。第三Agent、RAG、多模态这些概念正在从 demo 走向生产。过去大家看 Agent 只是 ChatBot 加一个插件按钮现在要考虑的是工具调用、权限管控、失败重试、结果校验、审计日志。工程复杂度成了真正的门槛而不仅仅是大模型的生成能力。第四创业者的机会更偏向“最后一公里”。谁能把模型接入企业流程谁能把召回率做到可接受谁能控制单次调用成本谁能解决数据安全合规谁就更有可能活下来。这句话虽然不是 Jeff Dean 的原话但从技术角度看这就是对话里“看清唯一生路”最朴素的工程解释。2. AI 创业技术选型速览先把技术选型放在一张表里看清楚。不同团队规模、不同客户类型适合的技术路线差异很大。技术层常见方案技术门槛主要成本适合团队基座模型商用模型 API、开源模型本地服务低Token 费用或 GPU 成本大多数应用团队微调与适配LoRA、QLoRA、全参微调中训练算力、数据标注需要特定风格、术语、格式的团队知识增强RAG、向量检索、重排中向量库运维、Embedding 费用企业知识库、客服、文档问答Agent 编排工具调用、工作流引擎、任务拆解中高多轮调用成功率、调试成本自动化流程、复杂任务处理本地推理vLLM、Ollama、SGLang、TGI中高GPU 显存、磁盘、运维人力数据不出域、离线环境应用交付Web 系统、开放 API、私有化部署中前后端开发、部署运维所有商业化场景这张表想表达的核心观点是90% 的 AI 创业团队不需要从零训练基座模型。模型层可以被快速替换真正需要长期投入的是上层的数据闭环、评测体系、应用集成和交付体验。如果你问“我现在该选哪条路”从成本角度排序通常是商用模型 API 起步、开源模型私有化兜底、LoRA 微调做特色、最后才是考虑更大规模的训练。排序的逻辑很简单先把业务跑通再根据客户反馈决定要不要为特定场景付出额外算力成本。3. 从“低估 AI”到技术栈重构AI 演进速度超出预期这件事对旧技术栈的冲击是结构性的。早期很多 AI 产品是“规则引擎小模型人工兜底”现在变成“大模型底座上下文管理外部工具数据回流”。新的技术栈里几个组件会反复出现模型网关。应用层不应该直接写死某一个模型服务地址而是通过网关层做模型切换、负载均衡、超时控制和成本统计。换模型、加模型、灰度上线都发生在这一层。Prompt 与上下文管理。不要小看这块工程成本。业务提示词会随着客户需求持续迭代如果没有版本管理和线上实验能力模型升级一次输出格式可能全变。向量库与检索链路。RAG 不是简单的“文档切块加向量检索”还要处理 Embedding 模型选择、混合检索、重排、引用溯源、切片策略和索引更新。任何一个环节做得糙答案质量都会明显下滑。Agent 调度与工具调用。现在主流模型逐渐支持稳定的 Function Calling/Tool Call但真正难的是工具定义的健壮性、多轮任务的断点恢复、结果校验和超时处理。评测与回归体系。这是最容易被创业团队忽略的部分。模型能力变化快每次升级、每个 Prompt 调整、每个数据更新都可能引入回归问题。没有一套可重复跑的评测集团队就只能靠感觉发版。日志与审计。AI 应用一旦进入企业环境输入输出日志、操作留痕、异常告警就不是可选项。尤其涉及客服、金融、政务等场景审计能力直接决定能否过客户验收。这些组件组合起来需要的已经不是传统“算法工程师”单点能力而是“算法后端运维数据”的复合工程能力。这也是为什么对话里的“看清创业者的唯一生路”从技术角度看更像是提醒团队把建设重心从模型层挪到工程层。4. 创业者的现实约束算力、成本与合规4.1 算力不是第一约束但显存是对小团队而言自己训练一个大模型几乎不现实数据、算力、分布式调优、推理优化每一项都烧钱。更现实的路径是两种用商用模型 API 快速验证或者基于开源模型做本地私有化部署。本地部署看起来便宜但门槛经常被低估。模型权重文件动辄几十 GB推理时需要评估显存占用、量化精度、并发吞吐、长文本显存开销。网上经常有人说“某张显卡能跑某个模型”但这个结论通常有前提条件量化方式、最大序列长度、并发数、是否开启长上下文优化。实际部署时必须按目标模型、目标业务场景做一次压测不能直接照搬别人的数字。4.2 成本是商业模式的硬约束AI 应用的成本不是一次性购买而是持续的运行成本。单次调用看起来只要几分钱乘以每天几万次请求再乘以 30 天就是一笔不小的支出。控制成本有几个常用手段高频相似提问走缓存、超长上下文压缩、检索结果先做相关性过滤、批量任务错峰执行、设置单用户配额和全局预算报警。这些手段看起来不性感但往往比“换一个更聪明的模型”更能决定项目能不能持续运营。4.3 数据是一道分水岭很多企业客户愿意付费核心诉求就是“数据不出域”。模型可以部署在客户内网但业务数据、权限体系、审计日志都必须满足客户要求。这个需求直接推高了交付复杂度你需要处理私有化环境里的依赖安装、模型文件分发、离线升级、许可证管理等一堆事务。如果做的是面向个人用户的产品数据边界同样重要。用户聊天记录、上传文档、生成内容哪些能用于模型训练哪些只做短期存储都要在用户协议里写清楚。尽量不要默认拿用户数据去优化模型除非有明确授权。4.4 合规不是上线前补的生成内容的合规风险要在架构设计阶段前置考虑。输出内容需要可审计、可撤回、可溯源涉及人脸、声音、品牌素材的生成类功能必须确认授权敏感场景要接入内容安全审核。更稳妥的做法是在产品上线前就准备好一份风险清单逐项确认数据来源、输出用途、平台协议和行业监管要求。5. 最稳妥的起步路径API RAG Agent如果今天准备从零做一个 AI 应用我的建议是先走一遍“API RAG Agent”的最小闭环而不是一上来就部署开源大模型。下面给出一套通用验证链路。5.1 先打通模型 API第一步是确认模型接口能通。大多数兼容服务都提供类似 OpenAI Chat Completions 的接口格式下面是一个通用 Python 调用示例。import requests # 请替换为实际服务地址与密钥 API_URL http://127.0.0.1:8000/v1/chat/completions API_KEY your-api-key def chat(messages, modelqwen2.5-7b-instruct): resp requests.post( API_URL, headers{Authorization: fBearer {API_KEY}}, json{ model: model, messages: messages, temperature: 0.3, max_tokens: 1024, }, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: result chat([ {role: system, content: 你是一个产品助手回答简洁准确。}, {role: user, content: 请用一句话说明 RAG 的作用。}, ]) print(result)这段代码的关键是确认三个东西接口地址、鉴权方式、返回字段结构。实际项目里建议把调用逻辑封装成统一模块方便后续接缓存、监控和重试。5.2 再接入 RAG 知识检索纯粹靠模型记忆回答业务问题很快会遇到“编造答案”的麻烦。RAG 的做法是先把企业文档切成片段做向量化用户提问时先检索相关片段再拼进 Prompt 让模型基于片段回答。下面是一个简化版流程用来理解链路结构。from sentence_transformers import SentenceTransformer import numpy as np # 通用示例实际项目请替换 embedding 模型和向量库 model SentenceTransformer(BAAI/bge-small-zh-v1.5) def embed_text(text): return model.encode(text) def search(question, chunks, top_k5): q_vec embed_text(question) scored [] for i, chunk in enumerate(chunks): d_vec embed_text(chunk) norm np.linalg.norm(q_vec) * np.linalg.norm(d_vec) score float(np.dot(q_vec, d_vec) / norm) scored.append((score, i)) scored.sort(reverseTrue) return [chunks[i] for _, i in scored[:top_k]] def build_prompt(question, chunks): context \n\n.join(chunks) return f请基于以下资料回答问题如果资料中没有答案请直接说明不知道。\n\n资料\n{context}\n\n问题{question}这套简化方案能跑通概念验证但生产环境下要换用正式向量库、增加混合检索和重排、设置权限过滤。文档切块策略也需要反复调切片太短信息不完整切片太长检索精度下降。5.3 最后加一层 Agent 工具调用当业务不只需要“问答”还需要“查订单、改状态、调用内部系统”时就需要 Agent 层。模型先判断需要调用哪个工具生成结构化参数系统执行工具后把结果返回给模型模型再生成最终回复。functions [ { name: query_orders, description: 查询用户订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id], }, } ] def run_agent(user_input): messages [{role: user, content: user_input}] resp chat_with_tools(messages, functionsfunctions) if resp.get(tool_calls): for call in resp[tool_calls]: result execute_tool(call[function]) messages.append({ role: tool, tool_call_id: call[id], content: result, }) resp chat_with_tools(messages) return resp[content]这里要特别注意工具调用不是一锤子买卖。真实环境里工具可能超时、返回空数据、参数格式错误Agent 必须具备失败重试、追问用户、终止任务这样的处理分支否则演示很流畅一上线就各种卡死。6. 本地部署场景什么时候值得做先回答一个问题有商用 API 为什么不直接用因为有些场景真的不适合。一个典型场景是客户要求数据不出域模型服务必须部署在客户内网。另一个场景是调用量大到某个临界点后按次收费比自持 GPU 更贵团队就会考虑本地部署。还有一种情况是产品形态是私有化交付客户本身要求一键部署包。本地部署的通用流程大致是检查硬件与驱动、准备模型文件、启动推理服务、验证接口响应、接入业务应用。下面给一份 docker-compose 模板实际镜像、模型路径、GPU 参数都要替换。services: llm: image: your-local-llm-service:latest ports: - 8000:8000 environment: MODEL_DIR: /models GPU_IDS: 0 volumes: - /data/models:/models deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]启动之后建议先用最简单的请求验证再看显存占用和服务日志。重点观察三个指标单请求首 Token 延迟、并发请求下的吞吐、显存是否持续上涨。如果显存持续上涨优先怀疑长上下文缓存或并发没有正确释放。本地部署最大的坑不是“模型跑不起来”而是“模型跑起来了但没人维护”。推理框架升级、模型文件更新、驱动兼容、日志采集、告警都在长期消耗人力。如果团队只有两三个人能走 API 就先走 API。7. 批量任务与接口集成AI 应用一旦进入业务流一定会遇到批量任务批量改写商品描述、批量识别合同图片、批量转写客服录音、批量生成运营文案。批量任务和单人调试的核心区别在于稳定性。批量任务需要一个可断点恢复、可重试、可监控的流程。最朴素的做法是准备一个任务列表逐条处理失败重试结果落库。import time from concurrent.futures import ThreadPoolExecutor def process_one(item): for attempt in range(3): try: result chat_with_llm(item[prompt]) return {id: item[id], status: ok, result: result} except Exception: time.sleep(2 ** attempt) return {id: item[id], status: failed} task_list [ {id: 1, prompt: 把这段产品介绍改写得更有吸引力}, {id: 2, prompt: 总结这份会议纪要}, # 实际项目从队列或数据库读取 ] with ThreadPoolExecutor(max_workers8) as pool: results list(pool.map(process_one, task_list)) print(results)并发数需要根据推理服务的吞吐调整。如果调用的是外部 API并发太大会触发限流如果是本地推理服务并发太大会拖垮 GPU。批量任务还要加上结果对比和人工抽检模型输出不是每个都合格自动任务完成后一定要有人工复核环节。8. 效果评估与长期迭代AI 应用没有“一次开发永久上线”这回事。模型会升级业务数据会变化用户提问方式会变化效果随时可能回退。没有评测体系就等于闭着眼睛开车。一个可执行的评测方案包含四步第一步整理评测集。挑 50 到 100 条真实问题覆盖正常场景、边界场景、拒答场景。比如客服场景既要测“运费怎么算”也要测“你们老板电话多少”这种不该回答的问题。第二步定义评分标准。简单做法是人工打分复杂一点做多维评分答案准确度、格式正确率、引用命中率、拒答合理性。第三步每次变更后跑回归。换模型、改 Prompt、改切片策略、换 Embedding都要跑同一套评测集对比前后得分。第四步线上监控。记录接口超时率、Token 用量、用户反馈、日志异常。上线后要设置成本上限防止某一天调用量暴涨直接把预算打穿。9. 常见问题与排查方法问题现象可能原因排查方式处理思路接口请求超时网络问题或推理服务过载查看日志、单独请求测试增加超时重试降低并发换取更强的推理服务GPU 显存不足模型过大、并发过高、长文本过长用nvidia-smi观察显存变化换量化模型、限制并发、减小最大生成长度回答内容不相关Prompt 不清晰或检索召回差单独测试检索模块标注测试切块策略增加重排补充分类过滤模型输出严重幻觉知识库未覆盖该问题对比问题与资料相似度增加引用溯源资料不足时让模型主动拒答成本快速上涨缺少缓存或配额限制查看用量报表加缓存压缩 Prompt设置预算告警批量任务大量失败单条任务异常导致链路中断看任务错误日志加失败重试、隔离坏数据、做任务状态持久化表格里的每一项在实际项目中都很常见。排错最关键的一步是先缩小范围先用最简请求验证接口通不通再逐层加业务逻辑不要在复杂链路里盲猜。10. 合规、版权与安全边界对话里提到“看清创业者的唯一生路”落到产品层面绕不开安全边界。如果产品涉及图像生成、声音克隆、数字人、人脸替换必须明确素材授权。生成一个明星脸、复制一个真实主播音色、使用一段受版权保护的音乐都必须先确认是否有合法授权。不能因为“模型能生成出来”就默认可以做商业使用。如果产品收集用户数据或企业数据需要做权限隔离和访问审计。不要在用户协议里含糊其辞不要默认拿用户数据做模型训练。企业内部使用 AI 工具也要明确哪些数据允许输入外部服务哪些只能走本地部署。训练数据、输出内容、调用链路、模型来源都要做记录。一旦出现内容纠纷有日志和授权材料才能解释清楚。AI 生成内容越来越多之后谁有完整的数据链路谁才敢接更严肃的商业场景。11. 总结从对话到行动“创业者的唯一生路”这句话本身有标题党的成分但技术判断很清晰模型层是巨头的主场应用层拼的是场景、数据、成本和交付能力。如果你看完这篇只记住几件事我建议是下面这几条。第一先用 API 跑通最小闭环再决定要不要自部署。第二把 RAG 和评测体系放在比微调更高的优先级。第三批量任务必须设计失败重试和人工复核不能裸跑。第四成本、数据授权、内容合规从第一天就考虑不要等上线再补。最值得先验证的场景是某个高频、具体、愿意付费的业务问题。问题越窄越容易做出效果越容易控制变量也越容易形成客户口碑。等这一条链路稳定了再扩展到相邻场景。接下来的半年模型能力大概率还会变但这四个环节的工程价值不会变场景定义、数据准备、效果评测、稳定交付。现在就可以拿一个真实业务问题按上面这套流程跑一遍。