大模型聚合平台需求调研表：从业务系统到模型接入

大模型聚合平台需求调研表：从业务系统到模型接入

准备建设大模型聚合平台时，很多需求并不是从“接入哪些模型”开始，而是要先回答：哪些部门会使用？要接入哪些业务系统？调用场景是什么？不同人员需要什么权限？谁负责持续维护？

如果这些信息没有结构化，后续容易出现需求边界不清、系统优先级难排、模型接入范围反复调整等问题。部署方可以在立项前，先用一份调研表统一收集信息。

一、部门与使用角色

建议先梳理平台的实际使用方：

• 需要接入大模型的部门有哪些？
• 每个部门的主要使用角色是什么？
• 使用人员是个人用户、业务小组，还是系统调用方？
• 各部门的使用场景是否已经明确？
• 是否存在跨部门共用的模型或业务能力？
• 是否已有统一的技术负责人、业务负责人和安全联系人？

这一部分用于明确平台的服务对象，也便于后续设计权限边界和责任分工。

二、业务系统与调用场景

围绕“模型将被哪些系统调用”进行登记：

• 需要接入的业务系统名称和所属部门是什么？
• 系统当前的调用方式和接口情况如何？
• 是人工操作为主，还是由业务系统发起调用？
• 预计接入的业务流程处于试点、建设还是存量改造阶段？
• 是否有调用日志、审计、异常处理等管理要求？
• 不同系统是否需要区分环境、应用身份或调用权限？

建议每个系统单独填写，避免只记录部门名称而遗漏实际接入对象。

三、模型类型与接入范围

模型调研不宜只记录模型名称，还应补充使用目的和接入条件：

• 计划接入的模型类型有哪些？
• 各模型分别服务于什么业务场景？
• 哪些模型属于优先接入范围，哪些属于后续评估范围？
• 是否需要区分文本、向量、多模态或其他模型能力？
• 模型调用需要哪些参数、返回格式和技术适配？
• 是否存在数据范围、部署位置或合规方面的前置要求？

如模型清单尚未确定，可以先填写“场景—能力—待评估模型”的对应关系，不必在需求初期直接锁定具体方案。

四、权限与管理要求

权限部分建议同时从人员、部门、应用和模型几个维度进行确认：

• 哪些人员可以发起模型调用？
• 哪些部门或应用可以访问特定模型？
• 是否需要区分查看、调用、配置和管理权限？
• 谁负责新增用户、调整权限和处理异常？
• 是否需要记录调用主体、调用时间、调用模型和调用结果等信息？
• 权限变更是否需要审批或留痕？

这里的目标不是预设产品能力，而是先把管理要求记录清楚，供技术方案和安全评审进一步核对。

五、部署与责任边界

在进入技术方案评估前，还应补充以下信息：

• 计划部署在什么环境，现有基础设施条件如何？
• 哪些工作由内部团队负责，哪些工作需要外部协助？
• 平台建设、模型接入、业务系统改造分别由谁牵头？
• 预计先验证哪些场景，如何判断是否进入下一阶段？
• 后续由谁负责日常运维、权限管理和需求变更？

可直接放入调研表的字段

部门名称｜业务负责人｜技术负责人｜业务系统｜调用场景｜用户角色｜模型类型｜优先级｜权限要求｜日志与审计要求｜部署环境｜系统对接人｜待确认事项

这份调研框架适合用于大模型聚合平台建设前的信息收集和内部沟通，不替代详细的架构设计、安全评审、合规判断或供应商技术核验。建议先完成部门、系统、模型、权限四类信息，再安排接口、部署和实施方案评估。

如需推动内部立项，可下载需求调研资料，结合本单位的部门结构、业务系统和模型接入计划进行补充：
https://ofweb.tokenkeji.com/download