如何使用Django REST API实现机器学习推理及代码放置最佳实践

你切换到前后端分离的REST架构后，前端仅通过接口请求JSON数据，本身就已经解决了之前整页重载的问题，只需要后端把推理逻辑封装成接口供前端调用即可。

关于推理代码的放置，首先明确：不推荐默认把推理代码写在models.py中，models.py的定位是数据库ORM模型定义层，仅用来存放和数据存储、字段映射相关的逻辑，和存储无关的推理代码塞进去不符合单一职责原则，会增加后期维护成本。

以下是不同场景下的最佳实践：

通用最优方案：独立服务层拆分 #

• 在你的Django应用根目录下新建services/文件夹，所有业务逻辑、机器学习推理代码都归类存放在这个目录下
• 你可以新建services/sentiment_scorer.py文件，把模型加载、推理计算的逻辑全封装成独立类或者函数，对外仅暴露类似get_negative_score(input_text: str) -> int的调用方法即可
• 视图层仅做参数合法性校验、调用服务层的推理方法、封装返回结果，不需要感知推理的具体实现细节
• 额外优化建议：可以把预训练模型的加载逻辑放在Django的AppConfig.ready()方法里，服务启动时仅加载一次模型到内存，避免每次请求都重复加载模型，大幅提升接口响应速度
• 优势：职责拆分清晰，后续如果要更换推理模型、或者给多个接口复用同一个推理逻辑，仅需要修改服务层代码即可，不需要动视图、模型层的内容

小项目快速迭代方案 #

如果你的项目体量很小，推理逻辑只有几十行，且后续没有扩展计划，也可以把推理逻辑封装成独立函数放在views.py中，和视图函数分开存放即可。只要后续逻辑复杂度上升，还是建议迁到独立的服务层目录。

不推荐的做法 #

• 不要把推理逻辑和参数校验、响应封装的代码混写在视图函数里，后续加缓存、加限流、复用逻辑的时候会非常麻烦
• 除非你的推理逻辑完全和某个数据库模型绑定，每次模型实例创建/更新时都要自动触发推理并将结果存入字段，否则永远不要把大段推理代码直接写在models.py中，就算是上述绑定场景，也推荐抽成服务方法后在模型的save方法里调用即可

内容的提问来源于stack exchange，提问作者harsh