241126) 무기한 프로젝트 중단과 새로운 방법

241126) 무기한 프로젝트 중단과 새로운 방법

2024년 11월 27일

subot 프로젝트는 중단됐습니다. #

거의 프로젝트가 중단됐다고 볼 수 있다. OCR 같은 경우엔 좀 쓸만 했지만 실시간 음성 STT기능은 자연어처리 공부가 필요해보였고 결정적으로 바이두에서 원하는 영상을 구해버린게 너무 크다.

진짜 whisper #

여러 ai 모델을 써본 결과 각각 다른 형태로 리턴되고 있었고 자체적인 데이터클래스로 통일시켜야할 것 같다. 현재는 faster-whisper에 맞춰진 상태이고, 자막도 잘 생성된다.

f189b02f-be02-43a4-9ab0-3e2d3d865ad3


번역기능 #

이전에 subot을 만들면서 번역기 모델의 문제점이 있었는데 중 → 한 번역할때 IT 용어도 번역해버리는 문제가 발생했다.

그런데 gpt 같은 LLM 모델은 전체 컨텍스트를 이해해서 알잘딱 해준다고 한다.

gpt 4o vs gpt 4o mini #

4o mini는 텍스트를 합치는 경우도 있는데 세그먼트 자체를 합치는게 아니라서 자막이 밀리는 현상을 볼 수 있다.
아마 자막 생성 후 번역 하는 과정은 무조건 4o를 사용하거나 전처리하거나 4o mini를 미세조정해서 사용해야 할 것 같고, 한문장씩 번역하는건 4o mini를 사용해도 될 것 같다.

3215f04c-1ccd-4b9d-bd30-039fa6eff6ca

물론 4o를 사용해도 영화 한편에 500원 정도라지만, 요금이 거의 20배니까.. 장기적으로 보면 4o mini 를 사용하고 전처리 작업을 따로 하는게 가장 좋긴 하다.


구현 #

번역 대상 #

  • 자막
  • 폴더/파일명

첫번째 시도 #

srt 파일을 파싱하는 전처리 과정을 거친 뒤 gpt-4o-mini 모델을 사용해서 한줄씩 텍스트만 번역시켰더니 문맥 파악도 잘 안되고 번역 품질도 떨어졌다.

system 메시지를 좀 더 변경해봐도 아쉬움이 남는 번역 품질인건 변하지 않았고, 자막 segment 하나 마다 시스템 메시지가 붙어서 토큰이 너무 많이 소비되는 문제가 있었다.

59b4de53-938f-4cb0-95b8-0e395c998a6c

두번째 시도 #

일단 앞 뒤 문맥이 gpt에게는 중요한 것 같아서 segment 10개씩 번역하는 것으로 생각해봤다. 앞 뒤 segment 2개씩을 포함한 총 14개를 한꺼번에 번역하도록 처리했다.

14개를 전달하고 gpt에게 돌렸을때 몇개의 자막 데이터가 병합되는 문제가 있었는데 gpt-4o-mini 를 사용했을때 너무 빈번하게 발생해서 번역할 자막 문장 사이에 구분자를 둬서 해결했다.

1SEGMENT_SEP = "!@#/!@#"
2
3# 문장 사이에 구분자 삽입
4texts_to_translate = f"\n{SEGMENT_SEP}\n".join([elem['text'] for elem in context_batch])
5translated_batch = translate_text(texts_to_translate, len(context_batch))
6
7# 번역 후 결과에서 해당 문장으로 스플릿
8[s.strip() for s in response.choices[0].message.content.split(f"\n{SEGMENT_SEP}")]

만약 번역 중 문장이 병합된다면, 문장의 수가 맞지 않을 것이고 체크해서 에러가 발생하도록 수정했다.

1# 번역한 라인의 갯수가 맞지 않는 경우.. (마음대로 병합해버릴 수 있으니)
2if len(context_batch) != len(translated_batch):
3    print("hmm.. count is not match!! ->", i, len(context_batch), len(translated_batch) )
4    print(context_batch)
5    print(translated_batch)
6    print(texts_to_translate)
7    raise

파일단위로 이미 처리된 파일들은 무시하도록 변경해서 같은 경로를 대상으로 여러번 돌릴 수 있도록 수정하고, 만약 위의 batch 사이즈가 맞지 않는 에러가 발생한다면 여러번 다시 요청하도록했다.

gpt-4o-mini 모델을 사용하면서도 최대한 에러 없이 잘 동작하는 것을 확인할 수 있다. 리트라이 횟수에 따라 모델을 변경하는 로직도 추가했다.

819d5a6b-043f-41f5-ab89-e7ad2405670e

들어보니까 나쁘지 않다. 아래 사진이 현재까지의 단점이 명확한 문장인데..
중국어가 영어랑 소리가 비슷한 한자를 써서 표현해서 Kotlin = Cotton, Java = zhāzhā = 쩌리 로 번역된 것을 볼 수 있다.

그래도 듣고 있으면 이해가 되는 부분이라 중국어를 모르는 입장에서 이정도만이라도 이해할 수 있다는건 정말 대단한 발전이 아닌가 싶다.

2f97f509-24e7-4691-bc0b-6b52b894250d

comments powered by Disqus