1. 项目概述
2019年成立的Jina AI是一家专注于多模态AI基础设施的创业公司，其核心产品神经搜索框架Jina和CLIP-as-service在开发者社区获得广泛关注。作为早期加入的工程师，我完整经历了团队从10人到超百人的扩张过程，深刻体会到AI创业公司特有的组织演进规律。
与传统互联网公司不同，AI团队在技术栈复杂度、人才密度要求和产品迭代节奏上都有显著差异。我们内部将这套经验总结为"AI团队的Scaling Law"，它包含三个核心维度：技术债务的指数级积累、人才梯队的非线性成长曲线，以及产品-市场匹配的延迟验证周期。
2. 技术债务的指数积累
2.1 框架耦合的陷阱
早期为快速验证产品假设，我们采用全栈式架构设计。当代码库从3万行膨胀到30万行时，模块间的隐性依赖导致每个新功能开发时间呈几何级增长。最典型的例子是2021年重构embedding服务时，需要同步修改17个关联模块的接口协议。
关键教训：AI基础设施层项目必须从Day 1建立严格的接口规范，建议采用Protobuf定义跨模块通信协议
2.2 实验系统的技术债
模型迭代产生的技术债更具隐蔽性。在对比测试BERT、RoBERTa和DeBERTa时，不同团队使用的评估脚本存在细微差异（如是否包含停用词过滤），导致最终指标不可比。我们后来专门开发了Experiment Tracker系统强制统一评估流程。
实践方案：
- 标准化实验模板（Docker镜像+配置清单）
- 评估指标计算统一使用Sacred库
- 模型产出物强制包含完整复现指令
3. 人才梯队的非线性成长
3.1 复合型人才密度
AI团队需要同时具备三种能力的人才：
- 算法创新能力（发表顶会论文）
- 工程实现能力（百万级QPS系统）
- 产品抽象能力（将技术转化为API）
这类人才市场供给不足，我们采用"内部培养+定向挖角"策略。例如从FAIR挖来2名研究工程师，同时将5名应届生送到Meta实习。
3.2 能力跃迁曲线
初级AI工程师成长存在明显临界点：
- 0-6个月：掌握工具链（PyTorch+Docker+K8s）
- 6-12个月：独立完成模块优化
- 12-18个月：具备系统设计能力
- 18+个月：形成技术判断力
我们设计了一套里程碑考核体系，每个阶段设置明确的技术评审点，避免过早赋予超出能力范围的职责。
4. 产品-市场匹配的延迟验证
4.1 技术成熟度错觉
2020年我们基于BERT构建的语义搜索服务获得95%的准确率，但客户实际使用时发现：
- 长尾query效果骤降至60%
- 领域专业术语识别率不足50%
- 实时响应要求导致成本飙升
最终花了8个月时间才实现商业可用的72%稳定准确率。
4.2 需求抽象困境
企业客户常提出模糊需求："想要像GPT那样的智能客服"。我们开发了需求拆解框架：
- 确定核心指标（如转人工率下降）
- 划定能力边界（是否处理支付场景）
- 设计降级方案（FAQ回退机制）
5. 规模化过程中的关键决策
5.1 技术选型原则
建立三层技术评估矩阵：
- 研究可行性（论文复现成功率）
- 工程可实现性（GPU利用率）
- 商业可持续性（API调用成本）
例如放弃自研向量数据库，选择与Milvus深度合作。
5.2 组织架构设计
按能力而非职能划分团队：
- 基础模型组（专注精度提升）
- 系统优化组（专注推理加速）
- 产品化组（专注API设计）
每个组配备算法、工程、产品三种角色。
6. 持续演进的基础设施
6.1 自动化评估流水线
构建包含3000+测试用例的验证体系：
- 模型效果（准确率/召回率）
- 系统性能（P99延迟）
- 商业指标（单次调用成本）
任何代码合并需通过完整回归测试。
6.2 知识沉淀机制
强制推行三项制度：
- 技术方案评审录音转文字
- 项目复盘文档模板
- 每周技术分享录屏库
这些材料成为新人入职的核心培训资源。
在AI基础设施赛道，规模化的本质是建立"技术深度×工程能力×产品思维"的复合优势。那些看似可以快速复制的功能模块，背后往往需要数月甚至数年的持续迭代。最深的体会是：在AI领域，慢就是快。
