3. 架构总览：智能寻源系统的分层架构与风险权重模块的定位
智能寻源系统并非单一算法模型，而是一个由数据层 → 算法层 → 决策层构成的工程化决策流水线。风险权重模块作为连接算法评估与业务决策的“价值标尺”，贯穿三层架构，但其核心逻辑实体位于算法层与决策层的交界处。本章从系统架构视角拆解各层职责，并明确风险权重模块的精确位置与交互关系。
3.1 三层架构总览
系统采用经典的分层解耦设计，每一层解决不同粒度的供应链问题：
| 架构层 | 核心职责 | 输入/输出 | 典型组件 |
|---|---|---|---|
| 数据层 | 多源异构数据的采集、清洗、标准化与特征工程 | 原始数据 → 结构化特征宽表 | ETL管道、供应商画像库、价格时序库、风险事件库 |
| 算法层 | 候选供应商的评分、排序与风险量化计算 | 特征宽表 → 多维评分向量 + 风险概率分布 | 寻源评分模型、风险预测模型、风险权重计算引擎 |
| 决策层 | 基于业务规则与风险偏好的最终供应商推荐与策略输出 | 评分向量 + 风险权重 → 推荐列表 + 风险预警 | 规则引擎、多目标优化器、人工复核看板 |
架构原则：数据层只负责“事实”，算法层只负责“概率”，决策层只负责“选择”。风险权重模块是唯一同时携带“概率”与“选择”语义的跨层组件。
3.2 分层架构与风险权重模块的定位
风险权重模块并非独立部署的服务，而是一组权重配置 + 计算逻辑 + 决策接口的集合体。其物理位置在算法层，但逻辑影响直达决策层。下图展示了三层架构中风险权重模块的精确嵌入位置：
3.3 风险权重模块的输入、计算与输出
风险权重模块在算法层内部承担“价值对齐”功能。其核心计算流程可概括为：
- 输入接收：从寻源评分模型获取价格竞争力分、质量合规分、交付可靠性分；从风险预测模型获取违约概率、舆情风险指数、供应链中断风险等级。
- 权重映射：根据业务线、品类、采购金额等级，从权重配置表中动态加载对应的风险权重向量
W = [w₁, w₂, ..., wₙ]。 - 加权聚合：执行
Score_final = Σ (Score_i × w_i) × (1 - RiskPenalty)，其中RiskPenalty由风险预测结果与风险容忍度阈值共同决定。 - 输出下发：将加权后的综合得分、风险调整因子、各维度贡献度打包为
WeightedResult对象，推送至决策层。
工程要点：权重配置表支持热加载，无需重启服务即可调整风险偏好。生产环境中建议将权重向量存储在配置中心（如 Apollo/Nacos），并保留版本历史用于回溯。
3.4 风险权重模块的决策层接口
决策层通过标准接口消费风险权重模块的输出。接口设计遵循轻量、可解释原则：
// 风险权重模块输出数据结构（伪代码）
{
"supplierId": "SUP_2024_ZH_0817",
"rawScores": {
"price": 92.5,
"quality": 88.0,
"delivery": 95.0
},
"riskIndicators": {
"defaultProbability": 0.023,
"reputationRisk": "low",
"supplyChainDisruption": 0.15
},
"weightVector": [0.35, 0.25, 0.20, 0.20],
"finalScore": 89.7,
"riskPenalty": 0.018,
"adjustedScore": 88.1,
"decisionSuggestion": "recommended"
}3.5 架构视角的关键设计约束
- 数据层不可见权重：数据层不感知任何权重配置，仅提供标准化特征，避免特征与权重的耦合导致维护灾难。
- 算法层无业务偏好：算法层只计算“客观概率”与“多维评分”，不内置任何业务规则或风险偏好。
- 决策层不重复计算：决策层不重新计算风险权重，只做规则匹配与多目标排序，保证决策链路可审计。
- 权重版本化：每次权重调整必须生成新版本号，并与寻源结果快照绑定，支持事后归因分析。
常见架构陷阱：部分团队将风险权重逻辑直接写在决策层的规则引擎中，导致权重调整需要修改业务规则代码，既违反单一职责原则，又无法进行A/B测试。务必保持权重计算逻辑在算法层独立封装。
3.6 架构总览小结
智能寻源系统的三层架构通过清晰的职责边界，将风险权重模块定位为算法层的“价值对齐枢纽”。数据层提供事实，算法层计算概率与权重，决策层执行选择。这种设计使得风险权重可以独立迭代、热加载、版本化管理，同时保持对决策层的完全透明。下一层级的架构细节将深入算法层内部，拆解风险权重计算引擎的具体实现策略。