融合模型算法工程师
Posted Updated
我们正在构建一个面向复杂任务的模型融合系统。它不是简单地接入单个大模型,而是通过多模型并行生成、候选答案分析、强模型合成、路由策略、流式输出和可观测评测体系,让不同模型在推理、代码、研究和工具调用等场景中形成互补。
这个方向的核心问题不是“哪个模型最强”,而是如何稳定、可解释、可复现地把多个模型的能力组织起来,并在质量、成本、延迟之间做工程化权衡。
我们希望找到一位能参与完整闭环的工程师:从 benchmark 设计、实验执行、问题归因,到系统设计调整、核心代码实现和验收指标沉淀。
你会负责
- 参与模型融合 gateway、评测 harness、实验 runner、trace/observability 等核心系统的设计与实现。
- 设计和维护开发 benchmark,覆盖代码、研究、终端操作、工具调用、多模型融合等关键能力。
- 跑模型组合、scaffold、routing、reasoning 转发、timeout/fallback 等实验,分析质量、成本、延迟和稳定性。
- 结合 trace、模型输出和用户反馈,定位系统失败原因,并把问题转化为可复现 case 和工程改进。
- 优化融合链路中的关键策略,包括候选生成、分析摘要、合成输入、流式处理、partial salvage、评分与验收。
- 输出清晰的实验记录、设计文档和结论,让团队能基于数据持续迭代。
我们希望你具备
- 有 Rust / Python / TypeScript 中至少一种语言的实际开发经验,愿意根据项目需要补齐技术栈。
- 是重度 AI 用户,对模型行为、agent、eval harness、benchmark、tool calling、streaming、上下文结构等底层细节有兴趣。
- 能独立设计和实现模块,也能根据实验结果调整系统设计。
- 有数据驱动的工作习惯:愿意写脚本、跑对照实验、看 trace、分析失败样本,并接受结果和预期不一致。
- 对 benchmark 保持必要的怀疑精神:会关注 case 质量、评分标准、数据泄漏、过拟合、代表性和可复现性。
- 有成本和延迟意识,理解模型系统不能只追求单点质量,也要关注吞吐、响应时间、稳定性和调用成本。
- 工程习惯扎实,重视代码质量、测试、文档、可维护性和可回滚性。
加分项
- 做过 LLM、RAG、Agent、评测系统、开发者工具、IDE 插件、代码生成工具或自动化测试平台。
- 熟悉 OpenAI-compatible API、Responses API、SSE streaming、tool calling、reasoning content 等接口细节。
- 有 async Rust、Axum、Tokio、Python eval pipeline、CLI 工具、前端实验看板经验。
- 做过 benchmark 设计、自动评分、人工评审、ablation、误差分析或模型对比实验。
- 能阅读模型、agent、eval 相关论文或开源实现,并转化成可验证的工程实验。
我们不特别看重
- 年龄、学历标签或大厂经历。
- 是否有非常标准的 AI 岗位 title。
- 是否已经完整做过同类系统。