2nd Iteration (Telegram Bot)¶

아키텍처¶

graph LR
  U[User]
  T(Telegram Bot)
  C(Celery)
  R(Redis)
  F(FastAPI)
  S(Splitter)
  M(Merger)
  G{"Model<br>T5 or Llama"}

  subgraph "Split/Merge"
    S
    M
  end
  subgraph "Message Queue"
    R
    C
  end
  subgraph "Inference API"
    F
    G
  end

  U<-->T
  T<-->C
  C<-->S
  C<-->M
  C<-->F
  F<-->G
  C<-->R

주요 변경사항:
1. Celery를 중심으로 전체 서비스를 구성하고 대부분의 작업이 비동기 처리가 가능하도록 변경하였습니다.
2. Telegram Bot을 통해 사용자가 직접 점역을 요청할 수 있도록 변경하였습니다.

상세¶

S3(like) Storage의 사용 여부¶

파일 생성과 임시 보관에 있어서 가장 많이 사용하는 방법이므로 초기에는 minio를 연결하고 추후 S3를 연결하려고 하였으나, 다음과 같은 이유로 사용하지 않기로 결정하였습니다.

파일 형태로 서버에 저장된다면, 저작권/정보 보호 문제를 고려해야 합니다.
- 가장 좋은 형태의 개인 정보 보호는 처음부터 저장하지 않는 것입니다.
- 비록 시각 장애인의 경우 점역 사본에 대해 관대한 입장이라고 해도, 그 사본이 서버에 남아있는 것은 문제의 소지가 있습니다.
굳이 따로 저장하지 않아도, telegram은 무기한 저장이 가능합니다.
- 봇과의 채팅은 개인이 각 메시지에 대해 삭제 권한을 가지고 있습니다. 파일이 업로드 된 메시지 ID를 저장하지 않는다면 해당 파일의 관리 책임은 사용자에게 있다고 주장할 수 있습니다.
- 이를 ToS를 통해 명시적으로 알리면 될 것으로 보입니다.

Message Queue¶

Celery¶

테크 데모가 아니라 서비스로 선보이기 위해서는 작업 대기열을 관리하고, 병렬로 처리할 필요성이 있습니다. 이에 다음과 같은 이유로 서비스를 구성하는 모듈들이 모두 Celery를 통해 연결되도록 하였습니다.

구성이 간단합니다. Python Queue로 찾으면 많은 수의 튜토리얼과 활용사례가 있어 검증되었다 볼 수 있습니다.
Celery Worker를 통해 모듈들을 관리할 수 있습니다.
- 추론의 경우 모델의 특성상 병렬 처리나 파이프라인 구성이 불가능하므로, 단일 수행만 가능하도록 실행해야 합니다.
- 다른 부분인 split/merge, telegram과의 상호작용 같은 부분은 널리 쓰이는 async 방식으로 처리되어야 합니다.
- Celery는 Worker의 실행 옵션을 통해 정확히 이러한 요구사항을 충족시킬 수 있습니다.

서비스 구성¶

각 모듈은 수행하는 작업이 다르고, 이에 따라 import되는 모듈을 다르게 설정해 주어야 합니다. Celery가 다른 Worker들의 decorator를 확인해야 연결하기 용이하므로 소스 코드 자체는 동일하게 사용했습니다. 각 워커 루틴 내에서 필요 모듈을 import 하도록 하여, 각 모듈이 사용하는 리소스를 최소화하였습니다.

Split/Merge¶

저번 iteration의 문서에서 언급하였듯, 의외로 문장을 나누고 합치는 과정은 애로사항이 있습니다.

Splitter¶

문장 단위로 나눌 때의 문제점: 실제로 어떻게 나뉠지 예측이 불가능 하다. (너무 길 수도, 짧을 수도 있다.)
1. 문장 기호나 개행 문자로 나누기: 처음 선택한 방법. 테스트 데이터에 문장 기호가 찍혀 있지 않은 부분이 있어 예상 보다 매우 긴 문장이 발견 됨.
2. 한국어 문장 분리기 사용: kss가 검색 결과에 많이 나와서 사용한 방법. 샘플로 넣은 문장들은 잘 나누는 것으로 보였으나, 실제로는 1과 큰 차이가 없었다.
문장을 나누는 과정은 문장의 길이를 체크하여, 일정 길이 이상이면 나누도록 하였습니다.
- 모델에 맞는 tokenizer를 사용해 token길이를 기준으로 하여 전달토록 변경.
- kss보다 안정적이며 docker image 생성 시간도 더 짧아졌다.

Merger¶

기존에는 웹페이지 상에서 무한정 대기하며 결과가 모두 도착하면 반환해 줄 수 있도록 했다.
- 주 타겟인 교재의 점역을 웹 페이지가 열린 채로 기다린다는 것은 사실 상 불가능하다.
Celery와 Redis로 어느 정도 극복함.
- Redis에 부분 결과를 모두 저장.
- 전체 완료되면 부분 결과들을 종합하여 반환.

Done & ToDo¶

Done¶

접근성 개선: 웹UI를 통한 점역이 아닌, 텔레그램 봇을 통한 점역 서비스로 확장
원문 분할 및 재조합 로직을 개선
추론 queue를 관리하는 방법을 개선
추론 모델 인스턴스를 관리하는 방법을 개선

ToDo¶

PDF 변환 부를 교체할 수 있도록 구조를 개선
ToS를 추가 - 파일 관리 책임에 대한 명시
Convert와 Merge 서비스를 분리
조금 더 낮은 유지 비용의 inference 방법을 강구