DeepInsight 系列 03：接入测试用于确认模型服务状态#

模块定位#

模型总览说明“有哪些资产”，接入测试说明“哪些资产可以被调用”。这两个问题必须分开。一个模型出现在台账里，并不代表它已经有推理服务，也不代表当前服务在线。

接入测试页的价值在于把能力边界说清楚。用户输入历史序列和 Top-K 参数后，系统应明确返回推荐结果、服务离线、未登记服务或请求失败，而不是把所有异常都处理成空列表。

请求流程#

页面加载时先读取可测试模型列表。用户选择模型后，输入历史行为序列和返回数量，前端把参数组织成请求体，提交给后端预测接口。后端再根据模型配置决定是否转发到具体推理服务。

对于已经登记服务的模型，后端会调用对应推理接口并返回推荐结果。对于未登记服务的模型，后端应返回明确状态，让前端说明该模型当前只完成资产展示，尚未进入在线推理流程。

状态分层#

接入测试至少需要区分四类状态。第一类是真实推理，模型服务返回了可解释的推荐结果。第二类是候选服务，系统知道它应该接入哪里，但当前服务不可访问。第三类是未登记服务，模型有资产但没有推理代理。第四类是请求错误，例如输入格式不符合要求或后端接口异常。

状态分层可以减少误读。用户看到失败时，能知道是输入问题、服务问题、配置问题，还是模型本身没有接入。

输入校验#

接入测试页的输入不能只靠后端兜底。前端需要检查空输入、Top-K 范围、分隔符格式和模型选择状态。后端还要做二次校验，避免非法请求进入模型服务。

输入校验的目的不是限制用户，而是让失败信息更可理解。推荐系统请求通常依赖历史序列，如果输入结构不稳定，返回结果就无法说明模型能力。

返回结果#

返回结果应包含推荐列表、服务状态、请求耗时和必要的说明。对于真实推理结果，可以展示推荐项排序和置信说明；对于不可用状态，应保留错误原因和排查提示。

页面不应该把不可调用模型伪装成可调用。课程展示中，明确展示“未接入”“离线”“缺少服务”比给出假结果更可靠。

与其他模块的关系#

接入测试结果可以为性能看板和可视分析工作台提供上下文，但不等同于离线评估。一次 Top-K 请求只能说明服务链路可用，不能代表模型整体性能。

因此，接入测试页负责验证服务状态，性能看板负责展示评估指标，可视分析工作台负责把请求记录、模型资产和指标说明放到一起复核。

阶段结论#

接入测试页让 DeepInsight 从“能展示模型”推进到“能验证模型服务”。它的重点不是让所有模型都显示成功，而是把真实推理、服务离线、未登记和请求错误分开展示。这个边界越清楚，项目越可信。