如何为多格式银行交易设计可维护的降级分类管道？

我正在构建一个Java/Spring应用，用于导入并解析不同银行的对账单，各银行提供的交易数据格式略有差异。解析完成后，将原始银行交易行归一化为如下通用对象：

public record ParsedTransaction(
    LocalDate transactionDate,
    BigDecimal amount,
    String merchantName,
    String description,
    String bankCategoryName,
    String mccCode,
    String transactionTypeCode
) {}

但并非所有字段始终可用：部分银行提供分类（如Groceries、Transport），部分提供MCC代码，部分仅提供描述或商户名；部分描述存在噪声，同一商户也会有不同格式。我需要将交易分类到自定义内部类别：

enum TransactionCategory {
    GROCERIES,
    TRANSPORT,
    RESTAURANTS,
    RENT,
    UTILITIES,
    HEALTH,
    ENTERTAINMENT,
    TRANSFER,
    UNKNOWN
}

我计划采用降级管道：

1. 优先用银行类别映射内部类别；
2. 若无则用MCC代码映射；
3. 归一化商户名和描述；
4. 匹配人工维护的商户别名字典；
5. 基于归一化描述的关键词规则；
6. 无匹配则返回UNKNOWN；
7. 后续拟加入ML分类。

为避免将所有逻辑放入单一服务的大量if/else，我设计了TransactionClassifier接口及多个实现类（BankCategoryClassifier、MccClassifier等），并通过链式服务执行分类：

public class TransactionClassificationService {

    private final List<TransactionClassifier> classifiers;

    public TransactionCategory classify(ParsedTransaction transaction) {
        return classifiers.stream()
            .map(classifier -> classifier.classify(transaction))
            .flatMap(Optional::stream)
            .findFirst()
            .orElse(TransactionCategory.UNKNOWN);
    }
}

现提出以下问题：

1. 这种链式降级方案是否适用于此类交易分类问题？
2. 如何将商户别名、MCC映射等人工维护的映射与代码分离？如存储到数据库、配置文件还是其他介质？
3. 如何保证系统扩展性，以便后续无需重写整个流程即可加入基于ML的分类？
4. 交易分类系统有哪些常见陷阱需提前考虑，尤其是不同银行字段不一致的场景？

注：我并非寻求完整实现或库推荐，主要验证分类管道架构及映射的可维护结构。

问题解答 #

1. 链式降级方案是否适用？ #

完全适用。这种责任链模式的实现完美匹配交易分类的降级逻辑：

• 每个分类器只专注单一规则，符合单一职责原则，代码更易维护和测试；
• 链式执行的顺序完全对应你设计的优先级（银行类别>MCC>商户别名>关键词），逻辑清晰；
• 单个分类器失败或返回空时自动降级到下一个，容错性好；
• 可以灵活调整分类器的顺序或增减分类器，无需修改核心流程代码。

2. 人工维护映射的分离方案 #

建议根据映射的特性选择不同介质，兼顾可维护性和性能：

• MCC映射、银行类别映射：属于静态规则，变更频率低但可能批量更新，适合存储在数据库（如MySQL、PostgreSQL），方便后台管理界面维护，也可缓存到Redis提升查询性能；
• 商户别名字典：可能需要频繁新增/修改（比如同一商户的不同命名），适合用数据库+缓存，轻量场景下也可使用YAML/JSON配置文件（但配置文件修改需重启服务，适合小范围使用）；
• 关键词规则：可以拆分为规则组存储在数据库，支持按优先级、类别配置，方便动态调整关键词匹配逻辑。

核心原则是：所有人工维护的规则都不应硬编码，通过统一的配置/数据访问层读取，避免修改代码重启服务。

3. 如何保证扩展性以加入ML分类？ #

基于你现有的架构，扩展ML分类非常顺畅：

• 新增MLTransactionClassifier实现TransactionClassifier接口，内部调用ML模型服务（本地模型或远程ML API均可）；
• 在TransactionClassificationService的classifiers列表中，根据优先级插入该分类器（比如放在关键词规则之后、UNKNOWN之前，或根据效果调整到更高优先级）；
• 如果ML分类需要异步处理或返回概率结果，可以调整分类器接口，支持返回Optional<TransactionCategory>或带置信度的对象，核心链式逻辑无需大改；
• 后续若需要混合规则和ML结果（比如ML置信度低于阈值时降级到规则），只需新增一个组合分类器即可，不影响现有流程。

4. 常见陷阱与规避 #

针对银行字段不一致的场景，需注意以下陷阱：

• 字段值的歧义性：不同银行对同一概念的命名差异（比如有的银行把“转账”标记为Transfer，有的是Internal Transfer），需在归一化阶段统一字段格式，比如将bankCategoryName转换为小写、去除冗余前缀；
• 缺失字段的默认处理：部分银行可能不返回MCC或商户名，分类器需提前判断字段是否为空，避免空指针或无效匹配；
• 噪声数据干扰：描述字段可能包含无关信息（比如交易时间、卡号后四位），归一化阶段需清洗数据（如去除数字、特殊符号，提取核心关键词）；
• 分类优先级冲突：比如某交易的银行类别映射为GROCERIES，但MCC对应RESTAURANTS，需明确优先级规则（你现有的链式顺序已经解决了这个问题）；
• 规则的边界模糊：比如部分商户同时属于多个类别（如超市内的餐饮区），需在映射规则中设置明确的优先级，或记录分类置信度便于后续人工修正。

内容的提问来源于stack exchange，提问作者Микита Опара