추천시스템을 통한 (업무 자동화, 유저 만족도 향상)

특이사항

1. 다양한 모델들을 병합하여 의사결정을 내려야한다.

• 다양한 모델들의 output을 score로 통합시켜 이들의 선형결합으로 의사결정을 할 수 있도록 한다.

2. DB에 계속 쌓이는 Dynamic 데이터를 사용한다.

• 데이터 파이프라인을 구성해야한다.
• SQLAlchemy 와 ORM을 조합하여 query를 구현한다.
• 새로운 tool의 필요성을 느꼈다.
  --> Apache Airflow를 적용해야한다고 생각하여, 공부중

3. 모델의 결과를 상당히 많은 제약조건들을 체크하며 최종 결과를 내야한다.

• 음식점과 고객사간의 그룹은 어떠한가?
• 음식점의 하루 제공가능량이 어떠한가?
• 음식의 하루 제공가능량이 어떠한가?
• 유저의 알레르기 정보는 어떠한가?
• 고객사의 지원 금액은 어떠한가?
• 고객사의 요구 조건은 무엇이 있는가?
  --> 샐러드 필수여부, 배제 음식점, 배제 음식, 필수 음식점, 필수 음식 등
• ...

4. DB를 확인하여 거절된 배정에 대한 재 배정을 진행해야 한다.

• 1. DB에 거절한 데이터를 넣을 때, 배정 파일을 실행시켜 재배정을 진행한다.
• 2. service에 거절된 데이터를 체크하고 재 배정하는 파일을 실행시키는 button을 추가한다
• 3. DB 모니터링을 위한 가벼운 클라우드 서버를 사용하여 특정 루틴에 따라 db를 확인하고 재배정을 진행한다.

느낀점

1. 누군가는 프로젝트의 모든 부분을 알고 있어야한다.

• 기업연계 프로젝트인 만큼 반드시 기업에 배포하고 이 프로젝트가 현업에 적용되었으면 했다.
  --> 모델에 데이터를 넣고, 결과들을 병합하여 의사를 결정하고, 이를 제공하기위해서는 반드시 누군가는 프로젝트를 다 알아야한다.
  --> 마지막까지 이를 위해서 노력하다보니, 내가 모든 과정들을 알 수 있었고 이것이 어쩌면 PM의 모습아닐까 하는 생각을 했다.

2. "블랙박스 모델"의 사용은 굉장히 꺼려진다.

• Kaggle 혹은 Dacon에 csv하나 넣어보고 점수 확인할때는 우린 결과물에 대해 큰 책임이 없다.
  --> 그렇기에 우리는 잘 모르는 모델이라도 fit, train 방법만 잠시 보고 모델을 사용해보곤 한다.
  --> 하지만 실제 큰 기회비용이 필요할 수 있는 선택에서 test score가 높다는 이유만으로 블랙박스 모델을 사용하는것은 꺼려진다.
  ----> 이건 겪어봐야지 알 수 있는 부분인것 같다...

3. 실제로 사용하기 위해서는 "디테일"이 필요하다.

• 유저가 있는 배포를 하기전에는 "멋진 모델을 만들고 이것으로 결과를 제공하겠어!"라는 생각 뿐이었다.
  
  
• 하지만 진득하게 처리해야할 다양한 exception 들이 존재하고 이것을 처리하는건 필요하고 지루한 과정이다.
  --> 하지만 이런 시간이 없다면 모델은 유저에게 제공할 수 없다!
  
  
• 제약사항은 soft한것, hard한것을 나누어야한다.
  --> hard : 이것은 반드시 지켜져야 하며 지켜질 수 없다면 시스템 오류를 발생시켜야 한다.
  --> soft : 이것은 지켜지는것이 좋으나, 지켜질 수 없다면 시스템 오류 대신 지키지 않은 상태로 진행해야 한다.