TLDR

• Muze라는 음악 SNS를 개발하고 있다.
• 노래 정보 검색 기능이 필요한데, 데이터가 부족한 상황이라 검색 결과가 좋지 않다.
• 필요한 데이터를 바로 검색 후 수집할 수 있도록 외부 API를 활용한다.
• 이 외부 API에 문제가 생기면, 앱에도 문제가 생긴다. 그리고, API에는 Rate Limit이 걸려있어서 요청 수가 제한된다.
• 외부 API의 의존성을 최소화하기 위해 fallback으로 사용할 API를 여러 개 두고, Token Bucket 알고리즘을 사용하여 요청을 분산시킨다.

서비스를 개발하면서 A-Z까지 전부 다 구현하기란 어렵다. 구현의 난이도 뿐만 아니라 효율면에서 부적절하다. 그래서 우리는 외부 API를 호출한다. 원하는 기능을 편리하게 사용이 가능하다. 한 가지 문제점이라면, 외부의 의존성이 생김으로써 내부의 문제가 아닌 외부의 문제로 서비스의 결함이 발생할 수도 있다는 점이다. 예를 들어, 쇼핑몰 서비스에서 외부 결제 시스템의 문제로 상품 결제가 이루어지지 않는다면, 실질적인 손해로 이어질 수 있다.

진행중인 사이드 프로젝트 Muze는 음악 취향을 공유하는 웹서비스이다. 자신이 좋아하는 노래를 게시하고 공유하는 기능이 메인 서비스다. 이 서비스를 위해서는 노래 정보들을 데이터베이스에 저장하고 검색하는 기능이 필요한데, 프로젝트의 규모상 '검색이 가능한 노래'의 범위를 정하기가 애매했다. 물론 적당히 구할 수 있는 노래들을 읽어와서 저장하는 방법도 있겠지만, 실제 사용자들이 사용하기에 매끄러운 서비스를 만들고 싶었다.

그래서 생각한 방법은 사용자가 검색 시에 음악 플랫폼(Spotify, Shazam 등)의 검색 API를 활용해서 결과를 리턴해준다. 음악 정보가 서버 내에 당장 없더라도, 정보를 반환해줄 수 있게 되는 것이다. 하지만 이런 처리는 외부 API에 대한 서버의 의존성이 생기게 된다. 우리 서버가 정상적으로 동작한다고 해도, Spotify의 서버에 문제가 생기면 고스란히 그 문제가 우리 서버의 문제로 돌아온다.

외부 API를 활용하는 것은 이미 결정된 사항이기 때문에 이 상황에서 내릴 수 있는 차선의 선택을 하는 것이 중요하다. Spotify 서버에 문제가 생긴다면, Shazam 서버를 활용하는 건 어떨까? 두 플랫폼 모두 문제가 생길 일은 극히 드물 것이다. 인풋 형식과 아웃풋 형식을 맞춰서 추상화된 RequestHandler 클래스를 작성한다.

from abc import ABC, abstractmethod

class RequestHandler(ABC):
	def __init__(self, api_client):
		self.api_client = api_client

	@abstractmethod
	def search(self, keyword, category):
		return 노래정보

class SpotifyAPIRequestHandler(RequestHandler):
	...

class ShazamAPIRequestHandler(RequestHandler):
	...

class YoutubeAPIRequestHandler(RequestHandler):
	...

노래 검색을 위해 활용할 API가 세 개나 생겼다. 그럼 이제 들어오는 요청들을 이 API들에게 어떻게 분배해줄지 설정해주어야한다. 요구사항은

1. 결과가 나오지 않을 경우(response.status_code !=200), 다른 API로 요청을 넘긴다.
2. 각각의 API의 Rate Limit을 초과하지 않는다.
3. 사용자 경험을 고려하여 최대한 빠른 속도로 결과를 리턴해준다. 로 정리가 가능하다.

이 요구사항을 충족시키는 방법은 Token Bucket알고리즘을 활용하여 Rate Limiting을 적용하는 방법이다.

토큰 버킷 알고리즘은 토큰을 기록하여 사용량을 조절한다. 토큰은 시간에 따라 일정량씩 채워지고, 등록된 함수의 호출 시점에 토큰을 사용한다. 만약 시간당 채워지는 토큰보다 더 많은 호출이 이뤄지면 잠시동안 함수 호출이 멈추는 원리이다.

TokenBucket 클래스와 이를 관리하는 APIManager 클래스를 만들어 토큰 버킷 알고리즘을 구현해준다. 각 API당 할당된 Rate Limit 정보를 기반으로 rate(초당 버킷에 채워지는 토큰 수)과 capacity(버킷이 담을 수 있는 토큰의 최대수)을 설정한다.

그리고, 서버 접속 사용자 수에 따라 프로세스가 추가된다는 점을 상기해야한다. 프로세스 간의 APIManager 인스턴스는 독립적인데, API 호출은 공유하기 때문에 이를 인스턴스 간 정보들을 공유할 수 있도록 설정해주어야한다. 인메모리의 Redis를 사용해서 rate, capacity, token 정보를 공유하도록 설정한다.

rate, capacity 설정을 위해서 API 문서에서 Rate Limit에 대한 정보들을 살펴보았다. Spotify같은 경우에는 Rate Limit을 30초동안 쌓인 요청수를 기준으로 잡는다는 이야기만 있고 최대 요청량은 적혀있지 않았다(내가 못 찾았을수도...). 그래서 concurrent.future 모듈을 활용하여 30초동안 보낼 요청 수를 조정하여 실험한 후 최대 요청량을 가늠하였다.

# num_worker=1,2,3,4,5, ...,9,10
[{'num_requests': 158, 'num_success': 158, 'num_failures': 0}, {'num_requests': 302, 'num_success': 301, 'num_failures': 1}, {'num_requests': 533, 'num_success': 307, 'num_failures': 226}, {'num_requests': 774, 'num_success': 311, 'num_failures': 463}, {'num_requests': 992, 'num_success': 342, 'num_failures': 650}, {'num_requests': 1208, 'num_success': 356, 'num_failures': 852}, {'num_requests': 1474, 'num_success': 414, 'num_failures': 1060}, {'num_requests': 1659, 'num_success': 390, 'num_failures': 1269}, {'num_requests': 1973, 'num_success': 405, 'num_failures': 1568}, {'num_requests': 2243, 'num_success': 402, 'num_failures': 1841}]

스포티파이 API는 30초동안 대략 300 - 400개 정도의 요청을 받아준다. 대체 API인 Shazam과 Youtube도 비슷한 수량의 요청을 받아준다고 할 때, 대략 우리 서버는 30초동안 1000개의 검색 요청을 처리할 수 있다는 이야기이다. 이 얘기는 Muze 앱 운영 중에 1001명의 유저가 검색을 한 번씩 하는 경우가 30초의 시간동안 한 번이라도 발생할 경우, 다운타임이 발생할 수도 있다는 이야기이다. (물론 300명의 유저가 생길지 안 생길지조차 모르는 상황이긴 하지만, 30초동안 검색 한 번은 너무 짜다. 보통 한 유저당 한번 이상의 검색을 한다.)

이런 문제는 검색이 호출될 때 백그라운드로 해당 노래 정보를 데이터베이스에 저장하는 식으로 구성한다면, 시간이 지남에 따라 이런 문제들은 해결될 수 있을 거라고 생각했다. 한 번 이상 검색된 정보는 데이터베이스에서 호출되는 방식이기 때문에, 시간이 지날수록 외부 API에 대한 의존도가 낮아질 것이라고 기대했다. 여기에다가 추가적으로 백그라운드 스케쥴러로 최신곡에 대한 크롤링을 주기적으로 수행한다면, 외부 검색 API의 의존성을 최소화하고, 괜찮은 사용자 경험을 제공해줄 수 있게 된다.

이번 글에서는 Rate Limit이 설정되어있는 API를 다루기 위해 고려해야할 부분들과 안정적으로 처리할 수 있는 Rate Limit 기법에 대해서 알아보았다. 검색 기능은 Muze에서 꽤 중요한 기능이다. 이런 중요한 기능을 외부 API에 의존해야한다는 점이 고민되긴 했지만, 부족한 데이터를 다 커버할 수 없는 초기 개발 상황에서 차선의 선택이 필요했다. 외부 API에 의존하되, 운영 시 생길 수 있는 의존성을 최소한으로 줄이고, 데이터가 쌓임에 따라 그 의존성을 아예 없앨 수 있다면, 꽤 괜찮은 시나리오라고 생각한다.

Introduction​

지난 10월 7일, 파이썬 3.13이 릴리즈되었습니다. 변경사항 중 가장 주목할만한 내용은 GIL을 키고 끌 수 있도록 변경한 부분이였습니다. 정식으로 GIL이 완전 제거 결정을 내리기까지는(제거하지 않기로 결정할 수도 있음) 약 5년정도의 시간이 걸린다고 하지만, 멀티쓰레딩이 어려웠던 기존의 파이썬을 생각하면 엄청난 변화라고 할 수 있을 것 같습니다. 이번 글에서는 GIL이 무엇인지, 왜 등장했고 왜 제거하기로 한 건지에 대해 알아보겠습니다.

GIL이 무엇일까요?​

GIL이 무엇인지 이해하기 위해서 우선 우리가 작성한 파이썬 코드가 어떤 식으로 돌아가는지 알아야합니다. 컴퓨터의 기본 동작 방식은 다음과 같습니다. 보조기억장치(하드 드라이브)에 저장된 코드를 읽어 메모리 공간(RAM)에 프로세스로써 올리고, CPU는 레지스터의 도움을 받아 RAM에 있는 명령어들을 처리합니다. RAM에 적재된 코드는 컴퓨터가 이해할 수 있는 언어로 번역(소스코드 ->바이트코드->기계어)되어야합니다. 언어마다 다르지만, 파이썬은 작성한 코드를 메모리에 올릴 때마다 인터프리터가 코드 한줄 한줄 이 번역을 수행해주는 인터프리터 언어입니다. 인터프리터는 사람이 작성한 코드를 CPU에서 수행할 수 있게 번역해주는 역할을 한다고 보면 됩니다. 그리고, GIL(Global Interpreter Lock)은 프로세스당 하나의 쓰레드만이 이 인터프리터의 제어권을 갖고 명령을 수행할 수 있게 하는 락(Mutex)입니다. 동일한 프로세스라면, 여러 쓰레드가 존재해도, 이 락을 소유하기 전까지는 명령을 수행할 수 없습니다. GIL은 멀티코어로 구성되어있는 최근 CPU들을(2024년 기준 인텔 i7은 최대 20개의 코어, 애플 M3는 최대 40코어 보유) 멀티 쓰레딩으로 활용할 수 있는 이점을 제약합니다.

GIL은 왜 등장한 것일까요?​

그렇다면 왜 파이썬에 GIL이 등장한 걸까요? 정답은 다수의 쓰레드를 사용하면서 생길 수 있는 Race Condition을 예방하기 위해서입니다. 더 자세히는 파이썬의 메모리 관리 방법과 연관되어있습니다. 파이썬에서는 Garbage Collection에 (Heap영역에서 더이상 사용되지 않는 객체들을 삭제) Reference Counting을 사용합니다. 어떤 객체의 Reference Count가 0이상이라면, Garbage Collection 대상에서 제외하고, 0에 도달한다면, 더 이상 사용하지 않는다고 판단하고 제거하는 식입니다. 그런데 이런 Reference Counting 방식은 같은 메모리 공간을 공유하는 쓰레드들끼리 같은 자원에 접근하는 Race Condition이 발생했을 때 문제가 생길 수 있습니다. Reference Counting에 대한 동시 접근으로 인해 삭제되어야할 객체가 삭제되지 않거나 유지되어야할 객체가 삭제되는 경우가 발생할 수 있습니다. 이런 Race Condition을 방지하기 위해 GIL이 탄생한 것입니다. (Java같은 경우, 특정 시점을 기준으로 garbage collection을 수행합니다.)

파이썬이 멀티코어를 활용하는 방법​

GIL이 있다고 해서 파이썬이 멀티코어를 아예 활용하지 못 하는 건 아닙니다. 파이썬은 웹 프레임워크나 머신러닝 등 다양한 분야에서 활용되는 언어입니다. 파이썬이 멀티코어를 활용하는 방법은 크게 세 가지로 나뉠 수 있습니다.

1. 멀티 프로세싱
2. C나 C++로 작성한 코드
3. CPython이 아닌 다른 인터프리터(PyPy, Jython과 같은) 사용 (추가로 GIL때문에 멀티쓰레드가 아예 의미가 없는 건 아닙니다. I/O작업시에 GIL은 자동으로 해제되기 때문에 I/O bounded 작업에서는 멀티 쓰레드가 동작한다고 볼 수 있습니다.)

파이썬 멀티코어 활용법1. 멀티프로세스​

멀티프로세싱을 활용하면 멀티 코어를 온전히 사용할 수 있습니다. 그림으로 그리면 이런 식입니다. GIL에 의해 제약받지 않을 수 있도록 각 프로세스마다 별도의 인터프리터를 둡니다. 웹 게이트웨이 인터페이스인 gunicorn은 일반적으로 위에 보는 것과 같이 멀티 프로세싱 방식으로 동작합니다. 여기서 한 가지 알아야할 점은 프로세스는 개별적인 메모리 공간을 요구하기 때문에 멀티쓰레드에 비해서 메모리 공간을 더 차지합니다. 그리고 이 메모리 공간 때문에 메모리를 공유하는 쓰레드에 비해 컨텍스트 스위칭 비용이 발생합니다.

파이썬 멀티코어 활용법2. C,C++ 작성 코드​

파이썬에서는 C나 C++로 작성된 코드를 수행할 수 있도록 C API를 제공합니다. 파이썬 인터프리터가 C 코드를 확인하면 제어권을 넘기는 방식입니다. 이렇게 되면 GIL 상관없이 C나 C++ 코드에서 사용하는 것처럼 멀티쓰레딩을 사용할 수 있습니다. 대표적으로 numpy나 pandas와 같은 데이터과학 모듈이 이 방법을 활용합니다. C 작성 코드의 빠름과 유연함을 활용할 수 있다는 점이 장점이지만, C, C++ 데이터 구조에서 Python 구조체로 변경하기 위해 어느 정도의 오버헤드는 발생할 것입니다.

파이썬 멀티코어 활용법3. CPython이 아닌 다른 인터프리터 사용하기​

CPython이 표준 인터프리터이긴 하지만, PyPy나 Jython, IronPython 등 다른 인터프리터들도 존재합니다. GIL은 CPython 안에 존재하는 락으로, 만약 다른 인터프리터를 사용한다면 쓰레드 제약에 대해 더 이상 신경쓰지 않아도 됩니다. (물론, 다중 쓰레드 사용에 따른 공유 자원의 Race Condition을 직접 신경써줘야하겠죠) CPython이 아닌 다른 인터프리터를 직접 사용해본 적은 없지만, 필요하다면 인터프리터의 장단점을 확인하여 상황에 맞게 적절히 사용해볼 수 있을 것 같습니다.

3.13은 GIL 없이 어떻게 동작하는 걸까?​

그럼 여기서 떠오르는 궁금증은 이미 잘 돌아가고 있는데, 왜 이제서야 바꾸는 걸까 입니다. 2007년에 파이썬의 창시자 귀도 반 로썸이 게시한 글에는 멀티 코어가 등장하면서, GIL을 제거하는 방안을 고민해보았지만, 딱히 성능적으로 이점이 없었다는 얘기가 있습니다. GIL을 제거하면 CPU위주의 태스크를 수행하는 멀티 쓰레딩 프로그램에서는 확실히 이점이 있겠지만, 기존의 싱글쓰레드 프로그램에서 성능적으로 손실이 있었기 때문에 정식으로 반영되지 않았다고 합니다. 실제로 GIL을 제거하려는 여러 프로젝트(대표적으로 Giletomy)들이 있었지만, 3.13까지는 정식적으로 반영될 정도로 효과적이진 않았던 것 같습니다. 하지만 GIL 없이 멀티 쓰레딩을 사용가능하다면, 확실히 개선할 수 있는 포인트들이 있을 것입니다. 쓰레드 간 메모리를 공유한다는 점을 활용하면 메모리 공간을 더 효율적으로 사용할 수 있고, 멀티프로세스 사용시 프로세스 간에 자원을 공유해야하는 부담도 덜 수 있습니다. 이 GIL 제거는 기존의 reference counting을 biased referencing, immortialization을 통해 가능해졌다고 합니다. 자세한 사항은 글이 길어져 생략하지만, 락을 걸지 않고, 어떻게 쓰레드 간의 Race Condition을 해결할지에 초점을 두고 키워드들을 살펴보시면 좋을 것 같습니다.

Outro​

지금까지 GIL이 무엇인지, 왜 파이썬에 GIL이 생긴 건지, 그리고 파이썬에서는 이런 제약을 어떻게 해결해왔는지에 대하여 알아보았습니다. 기존의 파이썬 생태계에서 어느정도의 최적화가 이루어진 상황이지만, no gil 도입을 통해 어떤 식으로 더 개선될 수 있을지 기대됩니다.

영상 링크 : ML/AI 개발자를 위한 단계별 Python 최적화 가이드라인

유튜브 추천 동영상에 흥미로운 영상이 올라왔다.

"ML/AI 개발자를 위한 단계별 Python 최적화 가이드라인"

네이버 파파고 OCR팀 문주혁 님의 DEVIEW 2023 영상이다.

OCR, 이미지에서 텍스트를 탐지하는 단계에서, 텍스트 박스 갯수가 많아지면 속도가 느려지는 이슈를 어떻게 해결했는지에 대해 이야기한다. 전에 일했던 회사에서 똑같이 겪었던 이슈였기 때문에 집중해서 봤다. 영상을 보고 내 나름대로 문제 해결을 위해 발표자분이 어떤 식으로 접근했는지 정리해보았다. 기술적인 부분보다는 문제를 해결하기 위한 자세에 초점을 두고 글을 작성했다.

1. 문제 배경
2. 문제 해결 방법
3. 내가 시도해볼 것(Takeaway)

문제 배경​

파이썬은 딥러닝 모델을 개발하기 위한 생태계가 잘 구성되어있다. GPU를 활용하여 딥러닝 모델을 학습/평가/서빙할 수 있는 pytorch, tensorflow 등 여러 프레임워크들과 고차원의 행렬 데이터들을 처리할 수 있는 pandas나 numpy와 같은 라이브러리들이 있다.

문제는 파이썬이 다른 언어들보다 느리다는 점이다. 모델 개발이 끝난 후, 딥러닝 모델의 앞단과 끝단에서 데이터를 처리하는 전처리나 후처리 또는 다른 부분들에서 속도가 느린 걸 발견할 수도 있다.

데이터 사이언티스트들은 보통 CS 백그라운드가 다른 개발자들보다 강한 편은 아니다. (물론 케바케겠지만) 내 첫번째 컴퓨터 언어는 파이썬이고, 비교적 최근에야 C나 C++ 같은 언어에 관심을 갖게 되었지만, 개인적으로 생각하기에 코드를 보고 '이런 부분을 고치면 조금 더 속도가 개선되겠는걸? 아 여기서 병목현상이 발생하는구나' 같은 컴퓨터 내부 동작 원리를 건드리는(또는 컴퓨터 내부 동작 원리를 알아야만 가능하다고 생각한) 생각은 많이 해보지 못한 것 같다.

그래도 완성된 딥러닝 알고리즘이 작동하는 방식을 제일 잘 이해하는 개발자는 모델을 담당한 데이터 사이언티스트 본인일 것이고, 속도가 개선되어야만 한다면 그건 데이터 사이언티스트의 임무일 것이다.

영상에서는 요새 핫한 모델 최적화 기법, 상당히 높은 지식 수준을 요구하는 고난이도 기술 대신, 우리가 시도해볼 수 있는 것 그리고 실질적인 결과물을 낼 수 있는 방법에 대해서 이야기한다.

문제 해결방법​

측정 => {문제 개선방법 시도 => 측정 => 결과 분석} x repeat => 문제 개선

측정​

문제를 해결하기 위해서는 우선 문제가 있다는 사실부터 인정해야한다는 말이 있다.

'속도가 느리다'라는 이슈를 해결하기 위해, 우선 속도 프로파일링을 진행한다. 문제 해결을 위한 가장 첫번째 단계는 문제 개선 여부를 측정할 수 있는 지표 설정이다.

파이썬에서 제공하는 timeit함수도 있지만, 코드 곳곳에 일일히 입력해야한다는 단점이 있다. timeit 대신 line_profiler라는 라이브러리를 사용했다고 한다. 전체 코드에 대해서 줄줄이 얼마만큼의 시간이 걸렸고, 몇 퍼센트의 비중을 차지하는지 알 수 있다고 한다.

문제 개선방법 시도​

해결해야하는 문제가 '속도가 느리다'에서 '우리 코드 중 어느 부분이 특히 느리다'로 문제의 범위가 좁아졌다. 이제는 문제를 개선할 수 있는 방법들을 나열한다. 무작정 이 방법, 저 방법 해보자 보다는 여러 측면/레벨에서 시도해볼 수 있는 것들을 체계화하는 것이 중요하다. 영상에서는 속도 개선을 위해 python level, semi-c level, c/c++ level 세 가지로 나누어 접근했다.

문제 개선방법 - python Level

문제 해결 방법들을 나열했다면, 가장 시도해보기 쉬운 것부터 시도해본다. 실패했을 때 비용이 적고, 가볍게 직접 시도해보면서 해결하고자 하는 문제가 조금 더 구체화된다는 장점이 있다. 문제 정의 시에 알지 못했던 부분에 대해 새롭게 알게 된다거나, 새로운 해결방법들을 추가해볼 수도 있다.

numpy나 opencv는 c와 c++로 작성된 라이브러리로 파이썬에서 작동할 수 있는 최적 속도를 어느정도 보장받는다. 그렇다고 해서 해당 라이브러리로 작성된 코드가 작성할 수 있는 최적의 속도라는 의미는 아니다. 개선할 수 있는 부분이 있을지도 모른다.

다시 한번, 문제 해결 방법은 여러가지가 있겠지만, 가장 시도해보기 쉬운 것부터 시도하는 것이 중요하다. numpy나 opencv에서 개선할 수 있는 부분을 찾으라고 해서, 안에 구동되는 동작원리를 파악하고, c++ 코드를 재작성하라는 의미가 아니다. 가장 쉽게 시도해볼 수 있는 방법은 '같은 라이브러리 내에서 코드 문맥에 조금 더 적합한 함수가 있을 수 있다. 더 알맞은 함수로 변경해보자'이다.

문제 개선방법 - Semi-c Level

파이썬 속도 개선을 위해 검색을 하다보면 항상 나오는 키워드가 있다. cython이나 numba. 결론만 말하자면, "pure python, 즉 라이브러리를 사용하지 않은 파이썬 자체 코드일 경우 눈에 띄는 성능 개선을 확인할 수 있지만, 다른 언어로 작성되어 이미 빠른 라이브러리를 사용할 경우, 그다지 좋은 성능 개선은 기대하기 힘들다"고 한다. 여기서 내가 생각하기에 중요한 부분은 '좋다고 해서 써봤는데?"라는 생각으로 시도한 방법에 대한 대응 방식이다.

시도한 방법은 생각보다 결과가 좋을 수도 있고, 좋지 않을 수도 있다. 하지만, 결과의 퀄리티를 떠나, 결과를 분석하는 단계는 항상 있어야한다. cython이나 numba를 시도하는 방법에 있어서, '파이썬 자체 코드 => 성능 개선 우수, 라이브러리 코드 => 성능 개선 미미'라는 결론에 다다르기까지는 여러번의 실험과 분석이 있었을 것이다(추측이긴 하지만). 한 번에 이런 결론에 다다르면 정말 좋겠지만, 배경지식이 없는 상태에서 실험 후에 명료한 결론을 내리는 것은 생각보다 쉬운 일이 아니라고 생각한다. 여러번 걸릴 수도 있겠지만, 각 시도마다 결과를 분석하고, 나름의 결론과 경험치를 쌓아서 실용적인 결론에 다다르는 것이 중요하다.

('시도해봤는데 결과가 잘 안나왔다. 이 방법은 구리다' 같은 결론이 아니라, 영상에서처럼 '이 방법은 이럴 때는 잘 작동하지만, 저럴 때는 잘 작동하지 않을 수도 있으니 참고하세요.' 같은 실용적인 결론이다.)

문제 개선방법 - C/C++ Level

만약 C/C++ implementation을 적용하기로 결정했다면, '시도해보기 쉬운 것부터 시도' 원칙이 다시 한번 적용된다. 전체 코드를 바꾸는 대신, 시간이 오래 걸리는 병목 함수를 찾고 해당 부분만 C/C++ 구현을 적용한다. 여기서 내가 생각하기에 중요한 부분은 두 가지였다.

첫째는 새로운 코드 적용이 항상 공식 문서에 제공된 example과 같이 딱 들어맞지는 않을 것이기 때문에, 내 상황에 맞게 활용하는 유연성이 필요하다는 점이다. 영상에서는 numpy의 ndarray를 C에서 지원하는 cv::Mat 형식으로 변환하기 위해 Numpy C api에서 제공하는 PyArray_FromAny와 c++에서 제공하는 PyArrayObject를 거친다. '어? 내가 원하는 기능을 지원 안 하네?'하고 바로 포기해버리기보다는 조금 돌아가더라도 어떻게 해결할 수 있을지 고민해볼 필요가 있다.

두번째는 직접 해봐야 안다는 점이다. 위에서 언급했다시피, numpy와 opencv 같은 라이브러리들은 C/C++로 구현되어 있기 때문에 어느정도 최적의 속도를 보장한다. 그렇다면, 해당 라이브러리로 작성한 코드 속도가 무조건 C/C++로 구현한 속도와 동일할까? 아니다. 영상에서는 라이브러리로 작성한 파이썬 코드를 동일한 로직의 C/C++로 변환했을 때, 50%에 가까운 속도 향상을 얻었다고 한다. 개발을 하다보면 이론과는 다른 결과가 발생하기도 한다. 이론을 맹신하지말고, 직접 시도해보는 과정이 필요하다.

(문제 해결을 위해 돌아서 풀어가는 과정(workaround)에 길을 잃지 않기 위해서는 기초지식과 다루고 있는 문제의 본질에 대한 이해가 필요하다. 또, 이론이 전부가 아니다. 직접 시도해보는 과정이 필요하다.)

내가 시도해볼 것들(Takeaway)​

영상을 보고 배운 점을 정리하자면 다음과 같다.

• 최적화를 위해 컴퓨터 내부 동작 원리를 알아야만 가능한 것은 아니다.
• 문제 해결은 측정 -> 해결 방법 시도 -> 측정 -> 결과 분석 의 반복으로 이루어진다.
• 문제 개선 여부를 측정할 수 있는 지표 설정하기
• 문제 범위를 좁히기
• 여러 측면/레벨에서 시도해볼 수 있는 것들을 체계화하기
• 각 시도마다 결과를 분석하고, 나름의 결론과 경험치를 쌓아서 실용적인 결론 내리기
• 새로운 방법을 내 상황에 맞게 활용하는 유연성 기르기
  • 기초지식 갈고닦기
  • 해결하고자하는 문제를 이해하기
• 이론을 맹신하지 말고, 직접 시도해보기

만족스럽진 않지만, 우선은 동작하는 어플리케이션을 배포했다.

(어플리케이션은 http://3.39.105.35:8090/에서 확인할 수 있다.)

아직 추가해야할 내용도 많고, 개선해야할 내용도 많지만, 한 번에 하기보다는 하나씩 작업하는 게 중요하다. 개선과정에 있어서 중요한 것은 자동화할 수 있는 부분은 최대한 자동화해서 개발 싸이클을 개선하는 것이다. 작업하는 내용에만 집중하고, 코드를 관리하기 위해서 Github Issue에 작업할 내용을 기록하고, 브랜치를 파서 작업했다.

현재 AWS LightSail에다가 어플리케이션을 배포하였는데, 이 배포 과정을 Github Action을 사용해서 자동화하려고 한다.

서칭해보니 AWS의 다른 서비스들에서는 배포를 위해 CodeDeploy라는 배포 서비스를 제공하는데, AWS-LightSail은 해당사항이 없다고 한다. 그럼 LightSail은 배포를 자동화를 할 수 없는 걸까?

AWS-LightSail Instance가 EC2와 비슷하다면, AWS-LightSail Container Service는 ECS(container service)와 비슷하다.

aws-cli에서 lightsail로 이미지를 푸쉬하고 배포하는 기능을 제공한다.

EC2를 사용하면 S3에 빌드한 소스를 넘기고, S3에서 CodeDeploy가 변경내용을 가져와서 인스턴스에 적용하는 방식이였는데, LightSail Container Service는 바로 이미지를 푸쉬하고 배포하면 되니 더 간편한 것 같다. (왜 CodeDeploy가 S3를 통해야만 하는지는 아직 잘 모르겠다.)

다시 본론으로 돌아와서,

LightSail Container Service에 배포하기 위해서는 Github Action이 다음과 같은 과정을 거쳐야한다. 여기서 action runner는 깃헙 액션에서 워크플로를 실행하기 위해 제공하는 임시 서버이다.

1. 깃헙 체크아웃 - 마스터 브랜치의 변경사항을 action runner에 반영한다.
2. aws-cli 중 lightsailctl을 사용할 것이므로, action runner에 aws-cli lightsail 플러그인을 설치한다.
3. 도커 이미지를 빌드한다.
4. 빌드한 이미지를 컨테이너 서비스로 푸쉬한다.
5. 푸쉬한 서버를 배포한다.

name: lightsail-deploy
on:
  push:
    branches: ['master']
  pull_request:
    branches: ['master']
permissions:
    contents: read

env:
  LIGHTSAIL_SSH_KEY: ${{ secrets.LIGHTSAIL_SSH_KEY }}
  LIGHTSAIL_HOST: ${{ secrets.LIGHTSAIL_HOST }}
  OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY}}
  LIGHTSAIL_USERNAME: ubuntu
  LIGHTSAIL_SERVICE_NAME: llmsummarizer-container
  AWS_REGION: ap-northeast-2

jobs:
  buildfastapi:
    name: Building FastAPI app
    runs-on: ubuntu-latest
    
    steps:
			# 1. 깃헙 체크아웃 - 마스터 브랜치의 변경사항을 action runner에 반영한다. 
      - name: Getting Code from Github
        uses: actions/checkout@v4
      - name: Updating to the latest versions
        run: |
          sudo apt-get update
          sudo apt-get install -y jq unzip
			# 2. aws-cli 중 lightsailctl을 사용할 것이므로, action runner에 aws-cli lightsail 플러그인을 설치한다.
      - name: Install Amazon Client
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          sudo ./aws/install || true
          aws --version
          curl "https://s3.us-west-2.amazonaws.com/lightsailctl/latest/linux-amd64/lightsailctl" -o "lightsailctl"
          sudo mv "lightsailctl" "/usr/local/bin/lightsailctl"
          sudo chmod +x /usr/local/bin/lightsailctl
      
			# 3. 도커 이미지를 빌드한다.
      - name: Build a Docker Container
        run: docker build -t llmsummarizer:latest .
      
			#4.빌드한 이미지를 컨테이너 서비스로 푸쉬한다.
      - name: upload image to Lightsail container service
        run: |
          service_name=${{ env.LIGHTSAIL_SERVICE_NAME }}
          aws lightsail push-container-image \
            --region ${{ env.AWS_REGION }} \
            --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
            --label llmsummarizer \
            --image llmsummarizer:latest
      
      - name: AWS authentication
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: ${{ env.AWS_REGION }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{secrets.AWS_SECRET_ACCESS_KEY }}
      
      - name: AWS Lightsail 연결 확인
        run: aws configure list
        
      #5.푸쉬한 서버를 배포한다.
      - name: Launching the Containers
        run: |
          aws lightsail create-container-service-deployment --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
          --containers file://aws-lightsail/deploymentconfig.json \
          --public-endpoint file://aws-lightsail/publicendpoint.json1

물론 액션이 한 번에 성공하지는 못했다. 예기치 못한 실패를 몇십번 거치고 나서야 액션이 잘 실행된 걸 확인할 수 있었다.

그렇다면 이번엔 라이트세일 페이지에서 배포가 성공적으로 되는 걸 확인한다.


서버도 무사히 잘 동작하는 걸 확인했다.

배포를 자동화하는 개발환경을 셋팅했으니, 개발속도와 피드백 주기가 조금 더 빨라질 것을 기대해본다. 그럼 이제 추가 기능과 성능을 개선해보자.

LLMSummarizer는 이미 한 번 진행한 적이 있는 프로젝트이다. langchain-youtube-video-summarizer라는 이름으로 작년 말에 진행하다가 그만두었다. 프로젝트를 제대로 완성시키는 경험을 하고 싶기도 하고, 도대체 뭐가 문제였길래 하는 생각에 같은 주제로 다시 프로젝트를 진행하기로 마음먹었다.

같은 프로젝트를 다시 진행하기 전에 우선 왜 그만두었는지 이유를 곰곰히 고민해보고, 똑같은 실수를 반복하지 않도록 하고싶다.

이전 프로젝트를 그만두게 된 원인을 몇가지 꼽아보자면 다음과 같다.

1. 코드 구조를 미리 설계하고 시작했다.

   프로젝트를 진행하기 위해서 미리 설계하고 시작하는 것은 중요하다. 코드 구조가 잡혔는데 새로운 기능들을 추가하다보면, 코드가 금방 지저분해질 것 같다는 생각이 들었다. 그래서 디렉토리 구조를 미리 나눠놓고, 거기에 코드들을 끼워맞췄다. 틀을 정해놨으니, 그 안에 맞추면 된다는 생각이였다. 하지만, 이상하게도 코드 라인이 많아지면 많아질수록, 관리하기 힘들어졌고, 뭐 하나 쉽사리 변경하기 어려워졌다.

   코드 구조는 정해져있는 절대적인 답이 있는 것이 아니라, 그 쓰임새에 맞게 합리적으로 조금씩 변화해가는 과정을 통해 결정된다. 구조에 대한 고민은 프로젝트 초기에 한 번 하고 마는 것이 아니라, 코드를 작성하면서 끊임없이 고민해야된다는 것이였다. 코드가 돌아간다고 괜찮다 생각하지말고, 나중에 다시 봤을 때, 혹은 전체 구조에서 알맞는 코드인지 가독성이 좋은지 주기적으로 검토하는 것이 중요하다. 마틴 파울러의 ‘클린 아키텍쳐’는 확장성이 좋고, 유지 보수성이 좋은 코드를 작성하기 위한 해법들을 잘 알려준다. 그리고 테스트 코드를 작성하면, 변경사항에도 안전성을 확보할 수 있다고 한다. 이번 프로젝트에서는 테스트 코드를 작성하고, 클린 아키텍쳐에서 말하는 내용을 잘 숙지하면서 진행해보려고 한다.

2. 프로젝트에서 샛길로…

   진행하면서 초기단계에서는 미처 생각하지 못 했던 사항들이 발생했다. 예를 들면, 음성파일을 텍스트파일로 변환하는 whisper 모델 같은 경우에는 직접 서빙을 목표로 했었는데, 서빙을 위한 클라우드 비용을 알아보니, 운영이 도저히 힘든 가격이였다. 이럴 때는 조금 찝찝하더라도, 애초에 계획한 목표에 도달하기 위해 우선 가장 빠르고 쉬운 방법을 택하는 게 맞지 않을까 라는 생각을 지금에서라도 해본다. 그 당시에는 어떻게든 이 문제를 해결해야만 다음 단계로 넘어갈 수 있을 거라는 생각이였다. 결과적으로 GPU이던 CPU이던 whisper를 로컬로 서빙할 수 있는 방법은 찾지 못하였고, 계획한 목표에도 달성하지 못했다. 결과만 봤을 때는 시간만 낭비한 셈이다. 우선은 openai에서 제공하는 api로 목표한 요약 기능을 구현하고, 추가 개선을 하는 상황에서 다시 접했다면 어땠을까 하는 생각이 든다. 심리적으로도 결과물이 이미 있으니, 조금 덜 부담을 가지고 문제를 해결할 수 있지 않았을까 아쉬운 마음이다. 기술부채가 나쁜 것만은 아니다. 상황에 맞게 현명한 판단을 하는 게 중요하다. 이번 프로젝트에서는 미흡하더라도 우선은 완성을 하고, 조금씩 개선해나가는 것이 목표이다.

그래서 우선 돌아가는 어플리케이션을 작성했다. 이미 이전 프로젝트에서 작성해놓은 코드들을 가지고와서 확장성을 고려하여 작성했다. 인풋에 대한 전처리와 요약 과정이 혹시 변경될 수 있을지 모르니, Inputhandler와 mapreducer를 추상화하여 변경 사항에 대처할 수 있도록 했다. 어플리케이션 배포는 AWS의 lightsail 인스턴스에다가 했다. 3개월 무료라는 점과 lighsail이 제공하는 간편성 그리고 서버 규모가 커지면 EC2로 손쉽게 옮길 수 있다는 점에서 채택했다.

어플리케이션은 http://3.39.105.35:8090/ 여기에서 확인할 수 있다.

물론 고칠 점이 많다. 하나하나씩 개선해나갈 예정이다.

if(kakao)dev2022 발표영상

카카오 개발자 컨퍼런스 if(kakao) dev 2022가 12월 7일부터 9일까지 열렸다. 이번에도 역시 흥미로운 주제들을 다룬 세션들이 많았는데(얼마전에 있었던 카카오 서버 다운 사건에 대해서도), 그 중 내 관심을 가장 끈 주제는 ‘실험을 잘한다는 것은 무엇일까’. 카카오 추천팀의 개발자 분께서 발표한 세션이였다.

업무에 딥러닝을 활용하는 개발자로써(딥러닝 개발자, 딥러닝 엔지니어, 딥러닝 리서치 사이언티스트 등등 다양한 텀이 있지만, 정확히 내가 어떤 범주에 속하고, 그리고 또 속하고싶은지는 아직 잘 모르겠다.) 성장하기 위해서 어떤 역량들이 필요한지 항상 고민하곤 한다.

빠른 구현을 위한 프로그래밍 능력, 당면한 문제 해결을 위해 딥러닝을 적절히 활용하는 창의성, 매번 업데이트되는 최신 트렌드를 잘 반영하여 코드와 모델의 성능을 기록하고 정리하는 능력 등등 정말 다양한 분야의 역량이 필요한 딥러닝이지만, 그 중 실무에서 가장 중요한 덕목은 아무래도 ‘실험을 잘하는 것’이라는 생각을 한 적이 있다. 그래서 많은 세션들 중 단연 ‘실험을 잘한다는 것은 무엇일까’라는 타이틀은 더욱 눈에 띄었다.

불확실성을 전제로 하는 머신러닝 특성상 100%의 정확도, 100%의 효율은 없다. 다만, 전세계에서 부리나케 연구되는 학문이라 빠른 페이스로 트렌드가 바뀌고 새로운 기술들이 세상에 나온다. 기존 솔루션이 조금은 부족했던 부분 플러스 ‘더 좋은 게 나왔다던데?’라는 소식을 들으면, 이제 개발자는 실험 모드에 들어가게 된다. 새로운 모델(여기선 모델이라고 뭉뚱그렸지만, 학습 방법, 데이터 처리 등 머신러닝에 관련된 다양한 기술을 말한다)이 ‘기존 모델보다 실제로 나은지’를 실험으로 입증해야하는 것이다.

물론 실험 결과가 기존 솔루션보다 낫다라는 결론이 나면 해피엔딩이다. 문제는 새로운 모델의 결과가 애매할 때이다. (원래 있던 문제는 해결하는데, 없던 문제가 생겼다거나. 분명 정확도는 좋은데, 모델 연산이 너무 무거워 해결하고자하는 문제에는 투머치라거나. 정말 다양한 방면에서 애매할 수 있다.) 그럴 때는 두 가지 옵션으로 정리가 가능하다고 한다. 솔루션을 포기하거나 아니면 보완하거나.

옵션1. 솔루션 포기​

솔루션을 포기하기로 결정했다는 것은 그동안 해당 솔루션을 위해 투자한 시간을 (어떤 의미에서는) 확실한 성과가 없이 버려야하는 것과 마찬가지다. 확실한 성과가 없으면 실험자 본인이 지치기는 물론이고, 실적을 내야하는 회사에서 살아남기는 힘들다. 그렇다고 해서 솔루션 포기가 그동안 했던 것들이 아예 티끌로 사라지는 것은 아니다. 진행한 실험 결과로부터 어떤 교훈을 얻을 수 있을지, 즉 ‘어떻게 다음 실험에도 도움이 될 수 있을까‘를 남기는 것이 중요하다고 한다. 실험을 반복할수록 경험이 쌓이고, ‘이 방향은 아니야’, ‘이 방향은 더 파볼만 한데?’하는 소위 말해 짬(?)이 생긴다. 이런 경험들을 어떻게 본인의 발전 뿐만 아니라 팀원들에게 도움이 될 수 있는 방향으로 기록하여 ‘팀의 발전’으로 기여할 수 있는지가 ‘실험을 잘 하는 기준’의 하나가 될 수 있지 않을까 싶다.

또한, 성능을 개선하기 위한 다른 솔루션을 찾아야한다. 다른 솔루션을 찾아야한다는 것은 지금 투자한만큼의 시간이 다시 필요할 수도 있음을 의미하고, 더욱 최악인 것은 다음 솔루션이 이번 솔루션처럼 ‘포기’로 돌아갈 수도 있음을 인지해야한다는 것이다. 또, 해당 솔루션을 애초에 선택한 이유는 ‘성능이 좋다더라’하는 이유에서였을텐데, 이렇게 두세번 찾은 솔루션의 성능이 애매한 것을 확인하게 되면, 어느 기준으로 새로운 다른 솔루션을 찾아야하는지 막막해지기도 한다. (나도 논문을 볼 때, ‘이 퍼블릭 데이터셋에 대해서 이만큼 엄청난 성능을 보였다!’ 하는 부분에 대해서는 연차가 쌓일수록 무덤덤해지는 것 같다. 이렇게 연구결과를 믿기 힘든 부분은 머신러닝의 특성상 아마도 실험 셋팅이 회사, 기관, 연구소마다 다른 탓과, 실무에서 사용되는 데이터와 학회에서 사용되는 데이터 간의 격차가 커서일 듯 싶다.)

포기한 솔루션은 내가 해결하지 못하였다고 접는 것이 아니라, 남들에게도 매력적인 솔루션으로 느껴진다면 계속해서 시도될 것이라고 한다. 마치 원탁의 기사에서 나오는 ‘엑스칼리버’처럼. (효율이 중요하고 영업이익을 내야하는 회사이지만, 구성원들이 매력적인 솔루션들을 충분히 시도해볼 수 있도록 하고, 실패하더라도 커뮤니케이션을 통해 팀 전체의 성장을 위해 교훈을 남기는 회사가 정말 좋은 회사가 아닐까 싶다.)

옵션2. 솔루션 보완​

솔루션을 보완하기로 마음먹었다면, 어떤 부분들을 보완할지 리스트업하게 될 것이다. 때때로 주어진 시간에 비해 보완해야할 부분이 너무 많아 어디서부터 시작해야할지조차 모를 때가 있는데, 그럴 때일수록 우선 순위를 설정하고 그에 맞게 하나하나 차근차근 고쳐나가는 것이 중요하다고 한다. 그렇게 우선순위를 설정하면, 보완하고 실험하고 실패하고를 반복하며 솔루션을 보완해나간다. 한 번만에 원하는 결과가 나올수도 있고, 수십번해도 안 될 수도 있다. 뚝심있게 실험을 풀어나가는 것도 중요하지만, 실험이 반복될수록 ‘매몰 비용이 발생’한다는 것을 인지해야한다고 한다. 어떻게 될 것 같은데… 될 것 같은데… 싶은 마음은 알겠지만, 물러서야할 때를 알아야한다는 것이다. 이 물러서야할 때를 알기 위해, 실험 전 ‘마무리 조건’을 설정해놓으라고 한다. (이 ‘마무리 조건’을 어떻게 정해야할지는 아직 잘 모르겠다. 사실 실험이 원하는 방향으로 진행이 안되면 찜찜하고 될 때까지 해내고 싶은데, 어떻게 마무리 조건을 설정해야 이만큼 했으면 할만큼 했다 싶은 생각이 들지 잘 모르겠다.)

결론적으로 실험을 하면서, 아래와 같은 질문들에 대한 대답이 물흐르듯이 나온다면 아마 실험을 잘 진행하고 있는 걸 거라고 한다.

Q1. 실험 결과를 어떻게 남겨야 다음 실험에 도움이 될 수 있을까?

Q2. 보완 실험은 어디서부터 진행하는 게 좋을까? (보완하면 좋을 점이 너무 많이 보인다.)

Q3. 마무리 조건을 어떻게 세우는 게 좋을까?

실험을 잘한다는 것​

실험을 잘 한다는 것은 ‘승부수’가 있다는 것이라고 한다. 그리고 이 승부수는 이 실험이 성공할 거라고 생각하는 이유라고 한다. 단지 ‘이번에 나온 논문의 성능이 좋다던데?’라는 이유보다는 ‘학습용 데이터가 부족한 우리 문제에 소량의 데이터만으로도 이 정도 성능을 뽑는 논문이 나왔대’라는 이유라면, 실험이 성공할 확률이 높다는 것이다. 좀 더 일반화하자면, ‘문제 환경(Environment)과 문제 해결의 핵심이 되는 특징(Key Feature)이 들어맞을 때, 솔루션이 적합하다.’라고 한다.

승부수에 따른 실험 결과 분석

1. key feature 구현을 제대로 했는지 확인
2. key feature가 실제로 문제 해결에 도움이 되는지 확인

승부수가 있으면, 실험 결과 분석이 쉬워진다고 한다. ‘승부수가 되는 key feature 구현이 제대로 되었는지 확인한다’와 ‘key feature가 실제로 문제 해결에 도움이 되는지 확인한다.’라는 두 가지 가이드라인이 생겼기 때문이다. 이 다음 스텝은 두 가지 가이드라인으로부터 차근차근 밟아나가면 된다. 만약 key feature 구현은 제대로 되었는데, 문제 해결에 도움이 되지 않는다면, 내 가설과 실제 상황이 다르다는 것을 의미함으로, 어떻게 다른지 비교 분석해나가다보면, 다른 실마리가 보일 것이라고 한다. 승부수는 실험을 위해 어느 부분에 집중해야할지 알기 때문에, 실험 사이클도 짧게 가져갈 수도 있다고 한다. 또 승부수는 위의 세가지 질문들에 대한 답변도 될 수 있다고한다. 예를 들어, 마무리 조건을 어떻게 설정해야할지 모를 때는 ‘key feature’를 올바르게 구현하고, ‘key feature’가 실제 문제 해결에 도움이 되는지 확인하는 것으로 마무리 조건을 설정하면 된다고 한다.

Q1. 실험 결과를 어떻게 남겨야 다음 실험에 도움이 될 수 있을까?

Q2. 보완 실험은 어디서부터 진행하는 게 좋을까? (보완하면 좋을 점이 너무 많이 보인다.)

Q3. 마무리 조건을 어떻게 세우는 게 좋을까?

⇒ Key Feature에 기반해서 판단하면 된다!

승부수를 잘 세우려면?​

1. 내가 풀려는 문제(+환경)를 이해해야한다.
2. 기존 솔루션에 대해 이해해야한다.
3. 내가 구현하려는 솔루션에 대해서도 깊이 있게 이해해야한다.

가장 중요한 것은 내가 풀려고 하는 문제와 환경에 대해서 잘 이해하는 것이다. 아무리 솔루션이 좋아도, 내 문제에 맞지 않다면, 틀린 솔루션이다. 이 좋은 솔루션을 내 문제에 맞게 활용하는 것 또한 문제와 환경에 대한 이해가 필요하다. 두번째는 기존 솔루션에 대해 이해해야한다고 한다. 기존 솔루션을 모르면, 내가 구현한 새로운 솔루션이 아무리 좋다고 해도, 어떻게 기존 솔루션과 다른지, 그래서 어떻게 새로운 솔루션이 더 나은 건지 모르게 된다. 세번째는 내가 구현하려는 솔루션에 대해서도 깊이 있게 이해해야한다는 것이다. 무얼 중점적으로 구현해야하는지, 어떠한 부분이 내 문제 해결에 적합한지 알아야 실험의 진행 방향도 알 수 있다.

추가 조언​

번외로 실험에는 파이프라인 결함과 같은 엔지니어링적인 요소가 성능에 큰 영향을 미친다고 한다. 이럴 때는 단순하게 시작해서 점점 하나씩 추가해가는 식으로 개발을 하면, 예기치 않은 결함을 피할 수 있다고 한다.

또, key feature가 잘 작동하지 않을 때에는 솔루션 자체가 아닌 환경이 원인일 때도 있다고 한다. 실험이 실패했을 때, key feature가 잘 동작할 수 있는 환경이었는지도 검토해보라고 한다.

마지막으로, 실험 과정에서 많은 실패를 경험하게 될 텐데, 그저 실패에서 끝내기보단 하나하나 교훈을 얻어가면서 실험을 진행하다보면 결국에는 좋은 결과가 나올 수 있을 것이라고 한다.

마치며​

좋은 딥러닝 개발자(또는 딥러닝 리서치 사이언티스트, 딥러닝 연구원)로써 내가 길러야할 역량은 무엇일까 하는 고민을 자주 하곤 했다. 딥러닝 문제를 근본적으로 잘 해결할 수 있는 수학, 프로그래밍 능력, 최신 트렌드를 따라가는 부지런함, 당면한 문제 해결을 위해 딥러닝 기술을 잘 활용하는 창의성 등등 많은 역량들이 중요하겠지만, 그 중 실험을 잘 하는 것이 실무 문제 해결을 위해 정말 중요하다는 생각을 했다. 카카오 if 세션 ‘실험을 잘한다는 것’에서 어떻게 하면 실험이 잘 진행되지 않아도 실패로부터 교훈을 남길 수 있는지, 솔루션을 보완하기로 했다면 어디서부터 보완해나갈지, 그리고 얼마만큼 했을 때 멈춰야할지에 대해서 배웠다. 무엇보다 실험을 할 때에는 찾은 솔루션이 어떻게 당면한 문제에 적합한지 아는 승부수가 필요하다고 한다. 실험 결과가 안 나올 때면, 다음 스텝은 어디로 가야하지? 그냥 포기해야하나? 더 잡고 있어야하나? 하고 고민할 때가 많았는데, 그동안 있었던 고민들에 정말 중요한 단서가 된 세션이였다. 역시 개발자 컨퍼런스는 시간을 내서 봐야되는 듯 싶다. 그럼 이번 글도 좋은 자양분으로 삼아 정진하자.

이 글은 테슬라의 CTO였던 Andrew Karpathy가 2017년에 쓴 Software 2.0이라는 글이다. 2017년 작성 당시, Andrew Karpathy가 뉴럴 네트워크에 대해서 어떤 생각을 가지고 있는지, 5년이 지난 지금 2022년에 뉴럴 네트워크는 어떻게 변화되었는지, 그리고 앞으로는 또 어떻게 변화할지 고민하면서 글을 번역해보려고 한다.

소프트웨어 2.0​

나는 사람들이 뉴럴넷을 ‘머신러닝 툴박스 중 하나’라고 소개하는 것을 가끔씩 보곤한다. 뉴럴넷은 그만의 장점과 단점이 존재하고, 여기 저기에 쓰이며, 캐글 컴피티션 우승을 위해 사용되기도 한다. (지금은 캐글 컴피티션에 뉴럴넷을 사용하는 것이 보편적인 일이지만, 2017년 당시에는 그다지 보편적이진 않았나보다.)

불행히도, 그들의 이해는 나무만 보고 숲은 보지 못하는 것과 같다. 뉴럴넷은 그저 또 다른 분류기가 아니라 우리가 소프트웨어를 개발하는데 있어서 근본적인 변환을 일으킬 시작점이다. 뉴럴넷은 소프트웨어 2.0이다.

소프트웨어 1.0의 전통적인 “기술 스택”은 모두가 잘 알고 있다. 파이썬, C++과 같은 언어로 작성되어있으며, 프로그래머에 의해서 직접적인 명시로 이루어져있다. 코드의 라인들을 한줄 한줄 작성하면서 프로그래머는 자신의 의도를 프로그램 스페이스에 명시해야한다.

반면에, 소프트웨어 2.0은 뉴럴넷의 가중치들과 같이 훨씬 추상적이고 인간에게 친화적이지 않은(human-unfriendly) 언어로 작성된다. 뉴럴넷은 너무나 많은 가중치로 이루어져 있기 때문에 (보통 수백만 개의 가중치로 구성된다) 어떤 인간도 이런 코드를 작성하는 것은 불가능하다.(필자가 시도해봄)


대신에, 우리는 의도한 프로그램의 행동에 어떠한 목표를 상세해주고(e.g. ‘인풋 아웃풋예시를 충족하는’, 또는 ‘바둑 게임을 이기는’ 등의), 서칭할 프로그램 스페이스의 부분집합(subset)을 명시하는 코드 골격(rough skeleton)을 작성하며(i.e. 뉴럴넷 아키텍쳐와 같은), 또 이 프로그램 스페이스를 찾는데 연산 리소스들을 사용하여 프로그래밍 목표를 달성한다. 뉴럴넷의 경우, 이 서칭 과정을 역전파와 SGD(stochastic gradient descent)와 함께 효과적으로 이루어질 수 있는 프로그램 스페이스의 연속적인 부분집합을 찾는 것으로 제한한다.


이 비교를 더 구체적으로 하기 위해서, 사람이 직접 소스코드를 엔지니어링하는 소프트웨어 1.0(e.g. .cpp 파일들)에서는 바이너리 파일로 컴파일된다. 소프트웨어 2.0에서는 소스코드는 1)목표하는 행동 양상을 정의하는 데이터셋들과 2)대략적인(많은 디테일이 채워져야하는) 코드 골격을 제공하는 뉴럴넷 아키텍쳐로 이루어져있다. 최종적인 뉴럴넷을 컴파일하기 위해서는 데이터셋을 학습시켜 뉴럴넷에 녹여내야한다. 오늘날 가장 실용적인 적용사례에서, 뉴럴넷 아키텍쳐들과 학습 시스템들은 **원자재(commodity)**로써 입지를 굳혀가고, 대부분의 액티브한 ‘소프트웨어 개발’은 라벨링되있는 데이터들을 선별하고 가공 정제하는데(curating, growing, massaging and cleaning) 집중되어 있다. 그리고 이것은 우리의 소프트웨어에 반복해 적용하는 프로그래밍 패러다임을 본질적으로 전환시키고 있다. 개발 팀은 이에 따라 데이터셋을 수정하고 키우는 2.0 프로그래머들(데이터 라벨러들)과, 모델 학습코드 인프라, 분석, 시각화, 라벨링 인터페이스들을 감싸고 있는 코드들을 유지보수하고 반복하는 소수의 1.0 프로그래머들로 나뉜다.

파고들어보니, 대부분의 현실 문제들에서 직접 프로그램을 짜는 것보다 데이터를 수집하는 것(또는 더 일반적으로 말하자면, 목표하는 행동을 정의하는 것)이 더 쉬웠다. 데이터 수집이 직접 코딩보다 쉽다는 이유와 아래에서 설명할 소프트웨어 2.0 프로그램들의 장점들 때문에, 우리는 산업들이 1.0 코드에서 2.0 코드로 전환되는 것을 목격하고 있다. 소프트웨어 (1.0)은 세상을 먹어치웠고, 이제 AI(소프트웨어 2.0)은 소프트웨어를 먹어치우고 있다.

지금 일어나고 있는 전환(Ongoing Transition)​

지금 일어나고 있는 전환들의 몇몇 예들을 간단하게 살펴보자. 각 예들은 직접 코드로 작성하기에는 너무 복잡해 포기하고 있다가 2.0으로 스택 전환이 되면서 근 몇 년 사이에 발전을 보인 분야들이다.

**Visual Recognition(시각 인식)**은 ****머신러닝(e.g. SVM)이 살짝 가미된(sprinkled on top at the end) 엔지니어된 피쳐들로 구성되어있었다. 그리고 우리는 큰 데이터셋(e.g. ImageNet과 같은)과 CNN 구조들의 스페이스 서칭을 통해 좀 더 강력한 visual feature들을 찾았다. 최근에는 해당 뉴럴넷 구조를 직접 서칭하지 않고, 서칭 자체를 뉴럴넷에 맡기게 되었다.

**Speech Recogntion(음성 인식)**은 ****수많은 전처리와 gaussian mixture 모델들과 hidden markov 모델들로 수행되었지만, 오늘날에는 완전히 뉴럴넷으로 수행된다. Fred Jelinek이 1985년에 쓴 인용에 따르면, ‘언어학자를 자를 때마다, 우리의 음성인식 시스템은 더 좋아질 것이다.’

Speech Synthesis(음성 합성)는 다양한 봉합 메커니즘(stitching mechanism)에 의해 시도되었으나, 오늘날에 최신 모델들은 오디오 시그널 아웃풋 그 자체를 생성하는 큰 ConvNet(e.g. WaveNet)들로 대체되었다.

**Machine Translation(기계번역)**은 어절 기반의 통계 기술들(phrase-based statistical techniques)로 시도되었었지만, 이것 또한 뉴럴넷으로 대체되었다. 필자가 좋아하는 구조는 weakly supervised 또는 아예 unsupervised한 환경에서 소스 언어에서 학습된 단일 모델이 다른 타겟 언어로 번역되는 다국어 셋팅이다.

Games. 룰 기반의 바둑 프로그램은 예전에 개발되었었지만, 어떤 프로그램도 AlphaGo Zero를 이기진 못한다. 필자는 DOTA2나 Starcraft 또한 그러리라 믿는다.

Databases. AI 밖의 전통적인 시스템들은 이미 서서히 전환을 겪고 있었다. ‘The Case for Learned Index Structures’는 기존의 cache-optimized B-Trees 알고리즘을 메모리에서는 10배가량(order-of-magnitude) 절약하고 속도 측면에서는 70% 이상 앞지르는 뉴럴넷으로 데이터 관리 시스템의 코어 부분을 대체하였다.

소프트웨어 2.0의 이점들​

왜 우리는 소프트웨어 2.0으로 복잡한 프로그램들을 이동시켜야할까? 가장 쉬운 답은 실전에서 더 잘 작동하기 때문이다. 하지만, 이 스택을 선호하는데에는 다른 많은 편한 이유들이 있다. 소프트웨어 2.0(예시 ConvNet)과 소프트웨어 1.0(예시 제품 레벨의 C++ 코드 베이스)을 비교하여 소프트웨어 2.0의 이점들을 몇 개 살펴보자.

계산적으로 동질적이다(Computationally homongeneous)

표준적인 뉴럴넷은 본질적으로 행렬곱과 ReLU와 활성화 함수(thresholding at zero), 이 두 가지 연산으로 이루어진다. 훨씬 더 이질적이고(heterogeneous) 복잡한 전통적인 소프트웨어의 요소들(instruction set)과 비교해본다면?

적은 수의 코어 연산 단위(core computational primitives. e.g. 행렬곱)를 위해 소프트웨어 1.0만 적용하면 되기 때문에, 소프트웨어 2.0이 훨씬 정확도/퍼포먼스 개런티 측면에서 훨씬 쉽다.

연산에 담아내기 수월하다(Simple to bake into silicon)

결과적으로 뉴럴넷을 돌리기위한 기초 셋팅(명령어 집합; instruction set)이 비교적 간단하기 때문에, 이 뉴럴넷들을 실리콘(연산장치)에 담기는 훨씬 수월하다. e.g) 커스텀 ASICs, 뉴로모픽 칩 (인간의 두뇌와 유사한 컴퓨터 칩) 등등. 세상은 저전력으로도 돌아가는 지능이 보편화될 때 바뀔 것이다. e.g) 기학습된 ConvNet, 음성 인식기, WaveNet 음성 합성 네트워크 등을 전부 다 합친 작은 인공지능(protobrain)을 담을 수 있는 작고 저렴한 칩이 나올 수도 있다.

지속적인 러닝 타임(Constant running time)

뉴럴넷 전파의 모든 반복은 FLOPS의 정도와 동일하다. C++ 코드 베이스를 사용했을 때, 생길 수 있는 다양성(variability)은 0이다. 물론, 다이내믹 연산 그래프(dynamic compute graphs)를 가질 수는 있겠지만, 그럼에도 실행 플로우(execution flow)는 보통 굉장히 제한적이다. 그런 관점에서 소프트웨어2.0에서 우리는 의도치 않은 무한 루프에 빠질 일은 거의 없다고 보면 된다.

지속적인 메모리 사용(Constant memory use)

위 특징들과 비슷한 맥락으로 다이내믹하게 할당되는 메모리는 없기 때문에 디스크가 스와핑될 확률은 거의 없고, 코드를 뒤지면서 메모리 누수를 확인할 필요가 없다.

휴대하기 편하다(It is highly portable)

매트릭 연산들로 이루어진 이 시퀀스는 클래식한 바이너리 코드들이나 스크립트들과 비교했을 때 어떤 연산 구성이든 실행하기 훨씬 쉽다.

애자일하다(It is very agile)

만약 당신이 C++코드가 있고, 누군가 그 코드를 두배 더 빠르게 돌릴 수 있길 원한다면(퍼포먼스 손실을 감안하더라도), 새로운 스펙에 시스템을 튜닝하는 일은 결코 쉬운 일이 아니다. 하지만, 소프트웨어 2.0에서 우리는 뉴럴넷에 채널의 반을 삭제하거나 재학습해서 조금의 퍼포먼스 손실으로만 스피드를 두 배 이상 빠르게 만들 수 있다. 이건 마술이다. 거꾸로, 데이터나 컴퓨팅 파워가 더 생겼다고하면, 뉴럴넷의 사이즈를 더 키우거나 재학습함으로써 당신의 프로그램을 개선할 수 있다.

모듈들이 이상적인 전체로 녹아들 수 있다(Modules can meld into an optimal whole)

우리 소프트웨어는 보통 공공 함수들, API들, 엔드포인트들을 통해 통신하는 모듈들로 쪼갤 수 있다. 하지만, 따로 학습된 두 개의 소프트웨어 2.0 모듈들이 상호작용한다면, 우리는 쉽게 전체(whole)에 대해 역전파할 수 있다. (한 개 이상의 태스크가 다른 뉴럴넷들도 역전파를 통해 가중치 업데이트를 공유할 수 있다는 뜻) 만약 당신의 웹브라우저가 자동으로 low-level 시스템 명령어들(low level system instructions)을 10 스택 다운 재 디자인해서 웹페이지들을 로딩하는데 훨씬 더 높은 효율을 냈다고 생각해보라. 얼마나 멋진 일인가. 아니면 컴퓨터 비전 라이브러리(e.g. OpenCV)에서 너의 특정한 데이터를 자동으로 튜닝해준다면? 소프트웨어 2.0에서 이런 건 기본이다.

당신보다 낫다(It is better than you)

그리고 마지막으로 가장 중요한 것은 뉴럴넷은 사람들이 만들어낸 어떠한 코드들보다(지금도 이미지/비디오와 소리/음성에서 사람의 코드가 차지하는 비율은 극히 적다) 좋은 코드이다.

소프트웨어 2.0의 한계​

2.0 스택은 단점들도 있다. 최적화 후에 결과물로 나온 거대한 네트워크들은 분명 잘 작동하긴 하지만, 어떻게 작동하는지에 대해서는 알지 못한다. 많은 응용 분야들에서 우리는 이해하지(설명하지) 못한 99% 정확도의 모델 또는 이해 가능한(설명 가능한) 90% 정확도의 모델을 선택할지 결정해야한다.

2.0 스택은 비직관적이고 당황스러운 방법으로 실패할 수도 있다. 아니면 더 쵝악은 ‘조용히 실패'하는 것이다. e.g) 학습 데이터 중 bias(편향, 여기서는 학습목표와 다른 데이터 특징이라고 이해하면 될 듯하다.)를 조용히 반영하는데, 이는 대부분의 경우 데이터가 수십만 개에 다다르기 때문에 정확히 분석하거나 평가하기 힘들다.

마지막으로, 우리는 이 스택의 이상한 특징들에 대해서 아직 알아가는 중이다. 예를 들어, adversarial examples와 adversarial attacks는 이 스택의 비직관적이 성향을 나타낸다. (여기서 adversarial이란 의도적으로 뉴럴넷에 학습목표와 다른 데이터를 학습에 적용하여 학습목표로부터 벗어나게하는 것을 말한다. 더 알아보고 싶다면 링크 참조)

2.0 스택에서의 프로그래밍​

소프트웨어 1.0은 우리가 쓰는 코드다. 소프트웨어 2.0은 평가 기준(’학습 데이터를 올바르게 분류해줘’와 같은)에 근거한 최적화에 의해 쓰여진 코드다. 최적화는 사람이 작성한 코드들보다 훨씬 더 나은 코드를 찾을 수 있기 때문에, 어떤 셋팅에서던 프로그램 자체는 분명하진 않지만, 반복해서 퍼포먼스를 평가할(e.g. 이미지 분류 잘했어? 바둑 게임 이겼어?) 수 있는지가 이번 전환(Transition)에서 중요한 주제가 될 것이다.


트렌드를 살펴보는 관점(lens)은 중요하다. 만약 당신이 소프트웨어 2.0을 단순히 ‘분류를 꽤 잘하는 뉴럴넷 또는 머신러닝 기술 중 하나'로 인식하기보다, 새롭고 떠오르는 프로그래밍 패러다임으로 인식한다면, 더 많은 예측들(extrapolations)이 뚜렷해질 것이고 더 할 수 있는 것들이 보일 것이다.

1.0 코드를 적기 위해 사람을 도울 어마어마한 양의 툴들을 만들어냈다.(IDE 구문 강조 기능, 디버거, 프로파일러, 함수 서칭, 깃 통합 등등) 2.0 스택은 데이터셋들을 축적하고, 마사징하고 정제하는 프로그래밍으로 이루어질 것이다. 예를 들어, 뉴럴넷이 몇몇의 어렵거나 흔하지 않은 케이스들에서 실패한다면, 우리는 코드를 적기보단 더 많은 라벨링 샘플을 적용하여 문제를 해결할 것이다. 데이터셋들을 축적하고, 시각화하고, 정제하고, 라벨링하고, 소싱하는 워크플로우를 돕는 소프트웨어 2.0 IDE를 누가 만들 것인가? IDE가 데이터 예시 단위 손실함수에 근거하여 잘못 라벨링된 이미지들을 띄워주거나, 예측을 통해 라벨링(프리라벨링)하는 것을 돕거나, 아니면 뉴럴넷 예측의 불확실성에 근거하여 라벨링할만한 데이터 예시를 제시해줄지도 모른다.

같은 맥락에서, 깃허브도 소프트웨어 1.0 코드를 위한 아주 성공적인 플랫폼(home)이다. 소프트웨어 2.0에도 깃허브와 같은 공간이 있을까? 2.0의 경우 저장소는 데이터셋이 되고 커밋들은 라벨들의 추가 및 수정이 되겠다.

전통적인 패키지 매니져들과 pip, conda, docker 등과 같은 서빙 인프라는 우리가 바이너리를 더 잘 배포하고 구성할 수 있도록 돕는다. 소프트웨어 2.0 바이너리를 효과적으로 배포하고, 공유하고, 임포트하고, 더 잘 작동하게 하기 위해서 우리는 어떻게 해야할까? 뉴럴넷에서도 conda와 비슷한 게 있을까?

짧게 말해서, 반복적인 평가가 가능하고 저렴하며, 알고리즘 자체가 명시적으로 디자인하기 어렵지 않다면, 어떤 도메인이던 소프트웨어는 점차 널리 퍼질 것이다. 소프트웨어 개발 생태계와 이 새로운 프로그래밍 패러다임이 어떻게 적응할지. 많은 기회들이 널려있다. 그리고 장기적으로 봤을 때, 이 패러다임의 미래는 우리가 AGI를 개발할 때, 소프트웨어 2.0으로 작성될 것이 점점 명확해지고 있기 때문에 밝다.

Takeaway​

Andrew Karpathy가 이 글을 낸 2017년은 구글 딥마인드에서 이세돌을 이겼던 알파고의 바둑실력을 초월하는 알파고 제로가 출시된 년도이다. 그리고 뉴럴넷의 획기적인 성능향상을 일구어낸, 이제는 자연어 처리부터 이미지, 음성 인식, 강화학습 등 거의 모든 분야에서 사용되는 Transformer가 세상에 알려진 년도기도 하다. 2022년 현재 돌이켜봤을 때, 위에 적어놓은 Andrew Karpathy의 모든 말들은 어쩌면 너무나 당연한 말일지도 모르겠다. 그의 말 중 많은 부분이 현실로 이뤄졌고 이뤄지는 중이다. 마치 높은 언덕에 올라가 저 멀리를 내다보는 선구자처럼. 가끔은 기술만 파고들다가 시야가 좁아지는 경우가 있다. 그럴 때에는 한걸음 물러서서 시대적 흐름으로써 ‘내가 하고 있는 일이 가지는 의미와 내가 사회에 기여할 수 있는 바는 어떤 것이 있는지’ 한 번쯤 생각해볼 여유가 필요하다.

Intro​

• Image Segmentation Model(이미지 분할 모델)은 픽셀 단위의 클래스 분류를 통해 이미지 내 물체를 탐지하는 모델이다.

Image Segmentation Model 중 하나인 DeepLabV3. 픽셀별 값을 예측해 물체를 탐지한다.

• segmentation model의 대표적인 모델 UNet. 2015년에 생명공학 분야에서 MRI나 전자현미경 이미지의 탐지를 위해 처음 나온 논문이다. (UNet: Convolutional Networks for Biological Image Segmentation) 벌써 7년이나 된 모델이고, 현재는 segmentation 태스크에서도 적용되기 transformer와 같은 다른 우수한 성능을 내는 모델들이 많지만, UNet은 여전히 segmentation 태스크를 가장 직관적인 방법으로 설계한 구조라고 할 수 있다.

• 이 UNet에 대해서 이렇게 글을 쓰게 된 계기는 현재 참여하고 있는 kaggle competition(UW-Madison GI Tract Image Segmentation)에서 UNet을 다시 공부하게 되었기 때문이다. 정확히는 2차원 이미지를 처리하는 vanilla UNet에서 변형된 3차원 MRI 이미지를 처리하는 2.5D UNet이다.

  참고 : UNet으로부터 파생된 UNet 구조들

  • Eff-UNET
  • UNET+, ++, 3+ (NestedUNet)
  • 3D UNet
  • 2.5D UNet

포켓몬 이브이는 품고 있는 돌의 속성에 따라 다양한 종류로 진화하게 된다. UNet이 이브이라면, 2.5D UNet과 다른 UNet 변형 모델들은 그 진화형 쯤 되지 않을까 싶다.

• 이번 글은 UNet에 대해서 간단하게 설명하고, UNet의 변형 모델인 2.5D UNet에 대해서 설명하고자 한다.

UNET​

모델 구조​

이름 그대로 인풋 이미지가 왼쪽에서 오른쪽으로 U자형 곡선을 타고 내려갔다가(contracting path;downstream;downsampling;encoder 등 다양한 이름으로 불린다) 올라가는 것(expanding path; upstream;upsampling;decoder)을 확인할 수 있다.

높이로 봤을 때 총 5개의 층으로 구분되는데, 층이 한 칸씩 낮아질 때마다 featuremap의 hxw 사이즈는 반으로 줄어든다.(갈색 화살표;2x2 max pool). 반대로 층이 한 칸씩 높아질 때에는 featuremap의 hxw 사이즈는 두 배가 된다(초록색 화살표;2x2 up-conv).

각 층에서 featuremap은 두 번의 3x3 conv과 ReLU를 거치는데, 각 연산마다 hxw 사이즈는 2씩 줄어들고(패딩이 없기 때문에 커널 사이즈(3x3)에서 하나 작은 2만큼의 사이즈가 줄어든다), 채널 수는 64부터 2배씩 증가한다.

e.g) 첫번째 레이어 피쳐맵 사이즈 $(L_{featuremap} - L_{kernelsize}+2L_{padding}) / L_{stride} + 1 = (572 - 3 + 2*0)/1 + 1 = 570$

그리고 한가지 주목할 점은 내려갈 때(downstream) 각 층의 마지막 피쳐맵이 보존되었다가, U자 모양에서 마주보고 있는 올라갈 때(upstream)의 featuremap과 결합(skip architecture)된다는 점이다. 예를 들어서, 첫번째 층의 마지막 피쳐맵(hxwxc = 568x568x64)은 동일한 높이의 맨 마지막 층의 피쳐맵(hxwxc=392x392x128)과 합쳐진다. 피쳐맵의 크기가 서로 다르기 때문에 더 큰 왼쪽의 피쳐맵 사이즈를 오른쪽의 피쳐맵 사이즈와 맞게 잘라준다. (e.g 568 ⇒ 392) 이렇게 서로 먼 위치의 피쳐맵을 더해주는 것은 초기 연산 단계(얕은 층, low-level)의 피쳐맵이 후기 연산 단계(깊은 층, high level)에까지 골고루 영향을 미치도록 설계한 구조이다. ResNet에서 residual layer(skip connection)로 가중치 소실 문제를 해결한 것과 비슷한 맥락이라고 생각하면 된다.

residual layer; layer를 거치면서 소실될 수도 있는 가중치를 identity layer로 뒷단에 다시 한번 더함으로써 gradient vanishing 문제를 어느정도 해소한다.

손실함수(loss function)​

손실함수로는 cross-entropy를 사용한다. 분류 모델이 인풋으로 들어온 이미지 한 장에 대해서 softmax값을 도출한다면, segmentation 모델인 UNet의 경우, 이미지를 이루는 각 픽셀에 대해서 softmax값을 갖는다.

이미지 분류 모델 기본적인 형태. softmax값(각 클래스에 대한 예측확률을 담은 아웃풋)을 도출한다.

이미지를 이루는 픽셀들 각각에 대해서 softmax값을 도출한다. prediction의 색깔은 클래스를 의미한다. e.g)갈색 : 소| 분홍색 : 나무|초록색 : 잔디| 파랑색 : 하늘

2.5D UNet​

• 의학 데이터에는 3D 데이터(volumetric)가 많이 존재한다. MRI는 대표적인 3D 데이터이다. 3D 데이터를 2D로 자르지 않고, 3D 자체로 사용해야하는 이유는 2D로 자르면 중복되는 정보가 많고, 3D 데이터로 구성되어 있을 때여야만 의미있는 데이터일 경우가 많기 때문이다. 예를 들어서, MRI로 촬영한 복부 사진의 단면 이미지들보다 온전한 3D 이미지 한 장일 때 더 유용한 정보인 것과 같다.

MRA(Magnetic Resonance Angiography)로 스캔한 동맥 3D 이미지.

• 3D 이미지의 세번째 차원값은 volume과 pixel을 합친 voxel이라고 부른다.
• 모델을 거친 3D 이미지 인풋의 voxel은 해당 위치에 타겟이 있을 확률값이 된다. 2D 이미지에서 UNet의 픽셀 결괏값이 해당 클래스에 대한 확률인 것과 같은 맥락이다.
• 이 3D 이미지를 핸들하기 위해서 2D에 차원을 하나 더 붙인 3D 컨볼루션을 사용할 수 있지만, 3D 컨볼루션은 연산 비용이 굉장히 큰 편이다.
• 그래서 2.5D UNet에서는 3D 컨볼루션을 사용하지 않고 효율적으로 3D 데이터를 핸들하고, 3D 차원에서 타겟값을 예측하는 3D image segmentation을 소개한다.

방법​

1. 3D 이미지를 다양한 방향에서 투영시켜 이미지 시퀀스로 만든다. 투영시키는 방법은 보통 Maximum Intensity Projection이나 Radon Transform을 사용한다.
2. 이미지 시퀀스로 만든 이 프로젝션 이미지들에 2D 컨볼루션을 다시 적용하고, 학습가능한 3D 재구축 알고리즘을 적용하여 3D 이미지로 다시 만든다.
3. 이미지 시퀀스를 타겟 오브젝트에 다시 투사해서 복원하는 과정에서 그림자와 같은 얼룩이 발생하는데, 이를 학습가능한 filtration(여과 연산)으로 개선한다.
4. 학습가능한 재구축(learnable reconstruction algorithm) 알고리즘을 통해 3D 이미지로 아웃풋을 도출한다. 다양한 방향에서 선형 backprojection을 적용한다.

이미지 재구축 연산자

모델 구조​

• M : MIP(maximum Intesity Projection)
• U : 2D Unet
• F : learnable filtration
• R : reconstruction operator using p linear backprojections for directions
• T : fine-tuning operator (average pooling followed by a learnable normalization followed by the sigmoid activation)

모델 구조

논문에서는 위의 3D 이미지 학습 방법론에, m개의 projection 이미지들에 대해서 전부 학습시키기엔 메모리 소모가 크니, 두가지 path를 사용한 random 2.5D 기법을 추가한다. projection 이미지 전체가 아닌 랜덤으로 일부를 뽑아 학습 효율을 극대화하는 방식이다.

path1. $\hat{y}_{aux}$

path1에서는 projection 이미지들의 각도를 랜덤으로 일부분 뽑아 UNet에 태우고, learnable filtration과 reconstruction 과정을 거쳐 3D 아웃풋을 뽑는다. UNet, learnable filtration, reconstruction 과정 모두 학습된다.

path2. $\hat{y}$

path2에서는 3D 인풋 x에서 나온 MIP 이미지들의 모든 프로젝션 방향을 생성한다. 그리고 UNet을 태운 후, m개의 프로젝션 이미지에 적용한다. 여기서 UNet은 학습되지 않고 고정된(frozen) 상태이다. m개의 UNet 아웃풋을 가지고, filtration F와 파인튜닝 T를 학습할 수 있게 된다.

손실함수​

이렇게 아웃풋으로 나온 $\hat{y}_{aux}$ 와 $\hat{y}$ 는 정답지 y와 dice-loss로 학습에 반영된다.

마무리​

• 복부를 찍은 MRI 영상 이미지에서 대장, 소장, 위장을 찾는 캐글 컴피티션에 참여하게되었다. 이 MRI 데이터는 복부의 여러 단면(slice)들로 이루어진 3D 이미지들이다. 이 3D 이미지로부터 물체를 탐지하는 태스크는 3D Image Segmentation이라고 한다.
• 3D Image Segmenetation 문제를 해결하기 위해 kaggle Discussion을 살펴보다, 2.5D UNet이라는 모델을 찾게 되었다.
• 2.5D UNet은 3D 컨볼루션을 사용하지 않고, 다양한 각도에서 타겟을 2D로 투사해(MIP;Maximum Intesity Projection) 이미지 시퀀스를 만들어 UNet에 태운 후, 다시 3D로 복원해서 3차원 내의 타겟 위치를 탐지하는 방식을 사용한다.
• 3D 컨볼루션을 사용하지 않기 때문에 연산량 부담이 적고, 여기에 논문은 다양한 각도를 랜덤 샘플링하여 UNet과 3D 재구축 웨이트들을 학습시키는 path1과 모든 프로젝션 방향에 대해 프리즈된 UNet과 3D 재구축 웨이트를 학습시키는 path2, 이 두 개의 방법으로 모델을 학습시킨다.
• MIP나 reconstruction operator, filtration operator와 같은 방법에 대한 자세한 설명이 없어서 조금 더 서칭 후, 업데이트하도록 하겠다.

이번에 리뷰할 페이퍼는 Multimodal Semi-Supervised Learning for Text Recognition이다. 2022년 AWS AI Lab에서 나온 ‘Multimodal’과 ‘Semi-Supervised’가 키워드인 텍스트 인식 모델이다. 우선 ‘Multimodal’부터 살펴보자.

MultiModal​

불과 5년 전만 해도 컴퓨터가 글을 읽는 일은 무리였다. 물론 단어 몇 개나 미리 지정해둔 트리거 신호를 사용해서 글자를 인식하는 경우는 있었지만, 한 이미지에 몇 백개가 넘는 글자를 오탈자 하나 없이 다 맞추는 것은 불가능에 가까웠다. 게다가 몇 백개의 글자를 포함한 이미지가 몇 만장이라면? 정확도는 현업에서 사용할 수 있는 수준이 아니였다. 하지만, 딥러닝의 발전과 함께 글자를 읽는 OCR(Optical Character Recognition) 특성 모델들이 발전하면서 이제 AI는 글자를 꽤 잘 본다. 꽤 높은 정확도와 사람이 따라올 수 없는 속도로 문서 이미지를 보고 그 안에 포함된 글자들을 내뱉는다.

네이버 OCR 결과 예시

보고 읽는다는 것​

하지만, 한 가지 아쉬운 점은 ‘**읽다’**는 것은 ‘본다’와는 다르다는 점이다. ‘읽다’라는 행위는 문장 성분 하나하나를 독립적으로 보는 것 뿐만 아니라 문맥(context)을 함께 이해하는 것이다. 대상이 단어라면, 단어를 구성하는 글자들을 유기적으로 이해하는 과정이 필요하고, 대상이 문장이라면, 문장을 구성하는 단어들 각각과 그 단어들이 서로 맺는 관계를 이해하여 문장을 인식하는 과정이 필요하다. (그런 의미에서 책을 읽는 건 우리가 생각한 것보다 훨씬 어려운 일일지도 모른다) 아래 그림을 한 번 살펴보자.

본다 ≠ 읽는다

사진의 간판에 뭐라고 적혀있는걸까? 이 사진을 ‘보기'만 했을 때, 추출해낼 수 있는 단어는 ‘보’, ‘설’, ‘렁'이다. 나무에 어렴풋이 가려진 글자가 두 개정도 더 있는 것 같지만, 해당 이미지를 기존의 OCR프로세스에 돌렸을 때, 나올 수 있는 결과는 ‘보', ‘설', ‘렁' 뿐일 것이다. 하지만, 사람은 이 이미지를 보고 나무에 가려져 보이지 않는 ‘탕'까지 유추해낼 수 있다. 보이는 글자 ‘설렁'을 보고 ‘탕’까지 읽어낸 것이다. 이것이 문맥을 이해했을 때 나올 수 있는 결과이다. 이처럼 사람은 ‘보고 읽는' 반면에, 현재(어쩌면 이미 과거의) OCR 프로세스는 ‘보는' 행위에 그친다는 단점이 있다.

이런 단점을 해결하고자 다른 데이터 도메인을 함께 활용하는(e.g: text + vision, vision + speech) multi-modal 연구들이 진행되고 있다. multi-modal 모델의 예로는 문장이 말한대로 그려주는 OpenAI의 Dall-E나 LG에서 개발중인 엑사원 등이 있다.(아래는 직접 뽑아본 Dall-E 이미지 아웃풋들이다.)

white horse face with carrot on the forehead, oil painting

van gogh style armored cat

armored maltese in battlefield

한 이미지에는 픽셀뿐만 아니라, 텍스트로써 이해할 수 있는 문맥들이 존재한다. 컴퓨터 비전과 자연어 처리를 융합한 이번 페이퍼의 모델 SemiMTR(Semi-Supervised Multimodal Text Recognition)은 이미지로 한 번, 그리고 텍스트로 다시 한 번 이미지를 인식한다.

Semi-Supervised​

딥러닝과 빅데이터 시대가 도래하면서 무엇보다 데이터의 중요성이 강조되었고, 그만큼 방대한 양의 데이터가 공개되었다. CNN과 같은 지도학습 모델은 데이터와 상응하는 답안지(라벨링)를 필요로 한다. 문제는 데이터의 양이 커질수록, 자연스럽게 컴퓨터가 답안지로 사용할 라벨링 비용 또한 커진다는 것이다. 쉴새없이 쏟아지는 데이터의 양에 비해 라벨링은 턱없이 부족하기만 하다. 그럼 어떻게 해야할까? SemiMTR모델은 1)가지고 있는 데이터를 더 효율적으로 활용하여 모델을 학습시키는 방법과, 2)모델을 사용해서 라벨링을 대체하는 방법을 활용한다.

1. 가지고 있는 데이터를 더 효율적으로 활용하여 모델을 학습시키는 방법

데이터를 더 효율적으로 활용하기 위해서 컴퓨터만 이해할 수 있는 공간에다가 가지고 있는 데이터들을 나열시킨다. 데이터를 나열시키면서 데이터 간의 관계(거리)를 하나씩 학습해나간다. 예를 들어, 학습이 제대로 이뤄졌다면, 단어 ‘king’과 ‘queen’ 간의 관계(거리+방향)는 ‘man’과 ‘woman’의 관계와 비슷하다는 걸 알게 된다. 독립적인 데이터 포인트 하나에 대해서 하나의 라벨링으로 학습하는 것이 아니라, 두 개 이상의 데이터 간의 관계를 학습해나가는 것인데, 이를 contrastive learning 기법이라고도 한다.

1. 모델을 사용해서 라벨링을 대체하는 방법

모델이 일정 이상의 성능을 확보했다고 가정하자. 99.999% 맞출 거라는 확신이 있는 데이터들만 따로 모아놓는다. 그리고 그 데이터들을 모델이 인식하지 못하지만 사람은 인식할 수 있는 수준의 변형(augment)시킨다. 그렇게 되면, 결과물로 모델이 생성한 99.999% 확신할 수 있는 라벨링과 모델이 아직 학습하지 못한(사람은 인식하지만) 패턴을 가진 데이터 먹거리가 생긴다. 라벨링이 없어도 모델이 자급자족할 수 있는 수단이 생긴 것이다.

아래는 논문을 읽고 요약한 내용이다.

Abstract​

• 최근까지 텍스트 인식기를 학습시키기 위한 실제 텍스트 이미지 데이터셋이 부족했었음
• 학습을 위해 합성 데이터를 사용한 지도 학습에 초점을 뒀었음
• 라벨링 없는 실제 텍스트 이미지들이 대량 방출됨
• 이 리소스들을 활용하기 위해, semi-supervised 방법들이 나오기 시작함
• 아주 소수의 방법들만 vision/language를 활용한 multi-modal 구조를 가지고 있음.
• 이 간극을 메꾸기 위해, multimodal 방식의 텍스트 인식기를 소개함 (SemiMTR)
• 해당 방법은 추가적인 학습 절차를 삼가하고, 현 3단계 multi-modal 학습 방식을 유지함
• 우선 vision 모델을 사전학습 시켜 self-supervised 학습과 supervised-학습을 합침
  • 더 자세히는, 기존의 visual representation learning algorithm을 확장시키고 글자인식을 위한 contrastive-based 방식을 소개함.
• 텍스트 뭉치들(corpus)를 사용해서 language 모델을 학습한 후에는 전체 네트워크를 약(weakly)과 강(strongly) 증강(augmented)된 텍스트 이미지들 간의 시퀀셜, 글자레벨, consistency regularization을 활용하여 파인튜닝함
• 새로운 셋업에서, consistency는 각 modality에서 각각 시행됨
• 추가 실험에서는 우리의 방법이 현 학습 스키마들의 정확도를 넘어서고, 텍스트 인식 벤치마크에서 최신 성능을 보여주는 것을 확인할 수 있었음

Introduction​

• ABINet이라는 모델 사용
  • 세 단계로 이루어져있는데, 이 단계들로 라벨링이 없는 실제 데이터들을 학습에 활용할 수 있음
    • supervised vision model pretraining
    • bidrectional language representation learning of the language model
    • supervised fine-tuning of the fusion model and entire
  • vision model을 학습시키기 위해서 label과 unlabel 데이터들을 contrastive learning으로 활용하는데,
    • contrastive learning의 핵심 아이디어는 같은 이미지이지만 다르게 증강된 이미지들의 representation 간의 동의율과 다른 이미지들 간의 분리율을 최대화하는 것
  • 더 정확히는 SeqCLR 기법을 적용함.
    • SeqCLR은 seq2seq contrastive learning 기법임 (원래는 손글씨 인식용으로 나옴)
    • 이 기법 적용을 위해, 더 로버스트한 transformer-based 백본을 채택했고, 더 강한 색깔-텍스쳐 증강기법을 적용했다.
  • 파인튜닝 단계에서는
    • 약증강과 강증강된 텍스트 이미지로부터 증강된 실제 텍스트 이미지 간 시퀀셜, 글자-레벨, consistency regularization을 진행한다.
    • 약증강 이미지로부터 인공 가짜-라벨시퀀스를 생성하고, 같은 이미지의 강증강 버젼을 전체 모듈을 학습시킬 때 라벨 시퀀스로 사용한다.
  • 실험을 통해, 각 모덜리티가 스스로 자급자족 학습(teacher of itself)하고, 각각의 학습을 위한 psuedo-label을 생성할 때, 가장 학습이 잘 진행된 것을 확인했다.

Related Work​

• Vision-language multimodal text recognizer
  • SCATTER - custom decoders for vision and language
  • SRN - global semantic reasoning module
  • SEED - offered a semantics enhanced encoder-decoder framework
  • VisionLAN - provide vision model w/ language capability
  • ABINET - vision-language multimodal architecture that possesss an explicit language model which can be pretrained on text corpus
• Semi-supervised learning for text recognition
  • case1. seq2seq domain adaptation techniques between labeled and unlabeld datasets
  • case2. seq2seq contrastive learning for visual representations learning
  • psuedo-labeling methods to utilize unlabeled images
  • confidence-based criterion for filtering noisy pseudo-labels
• Consistency Regularization
  • self-supervised learning에 널리 쓰이는 기술
  • core idea : model predictions should remain the same under each semantic-preserving perturbations of the same image
  • case1. enforces the network to be agnostic to some transformations and disturbances
  • case2. proposes a consistency regularization in semi-supervised settings by using noise injections and augmentations on the unlabeled examples
  • FixMatch : classification task에서 unlabeled 데이터에 대해 psuedo-labeling을 한 consistency regularization함.
    • strongly augmented version으로부터 나온 predictions와, 같은 이미지지만 weakly augmented version으로부터 나온 pseudo-label과 매칭하도록 학습한다.

Architectural Background​

1. pretrain vision model
2. pretrain language model via a version of masked language modeling
   • mask the attention maps instead of input characters
3. end2end fine tuning stage via supervised cross-entropy losses on the vision, language, and fusion predictions

SemiMTR: Multimodal Semi-Supervised Learning​

vision model ⇒ vision features ⇒ vision prediction ⇒ (gradient stop) ⇒ language model ⇒ contextual features ⇒ combine visual + contextual features ⇒ fusion prediction

Vision Model Pretraining​

• 사전학습에 unlabeled real data 포함
• 마지막 학습 phase에 unlabeled data만 사용하는 competitive semi-supervised methods가 vision model의 성능을 개선하였다
• SeqCLR + Transformer-based backbone

• 각 이미지를 두 번 augment ⇒ 각 visual backbone 과 projection head에 feed
• instance-mapping 함수 적용 ⇒ 각 증강된 이미지의 representation 시퀀스를 만들어 sub-word 단위의 contrastive learning이 가능하게 함
• 각 평행한 브랜치에서 라벨링 데이터의 visual prediction의 supervised loss 계산

사전학습은 6개의 빌딩 블럭으로 이루어져있음.

stochastic data augmentation

• 인풋 이미지에서 두 개의 augmented view 생성

Visual backbone

• ResNet + Transformer units

Projection head

• optional auxiliary network
• transforms the visual backbone features into a lower dimensional space

Instance-mapping function

• unique block for seq2seq predictions divides each feature map into a sequence of separate representations over which the contrastive loss is computed
• 기존 contrastive 방법과 달리, 전체 이미지들이 아닌 시퀀스를 이루는 개별 성분들 간의 contrasting이 가능하게 합니다.
• window-to-instance mapping 방식을 사용

  • feature map들의 배치가 NxFxHxW ⇒ NxH*WxF가 되도록 펴고,

  • adpative average pooling 적용해서

  • flatten된 각 featuremap으로부터 T개의 독립된 representation 추출하여 Z 세트로 모음

    $Z=AdaptiveAvgPool2d(Flatten(P))$

  • 이 함수는 두번 호출되어 각 augmented view로 적용

Contrastive Loss

• 같은 인풋은 augmentation과 상관없이 더 가깝게, 다른 인풋은 더 멀게 학습하기 위한 손실함수
• Noise Contrastive Estimation(NCE) loss function

cosine distance

Vision decoder and supervised loss

• SeqCLR 과 contrastive learning methods에서 supervised training phase는 self-supervised stage가 끝나고 진행됩니다. 하지만, semiMTR은 학습 스테이지들이 늘어나는 걸 막고, 통합된 semi-supervised training scheme을 진행합니다.

Consistency Regularization for Fusion Model Training​

• pseudo labeling을 사용하여 추가 재학습 과정이 필요한 다른 semi-supervised learning 방법과는 다르게
• self-supervised learning을 위해서, 파인튜닝에 더 적합한 sequential, character-level, consistency regulaization을 진행
• weakly-augmented version에서 라벨 추출
• strongly-augmented version에다가 추출한 라벨 적용해서 학습

Stochastic strong and weak augmentations

• 여러 color-texture augmentation method를 실험함
• 그중 가장 효과있는 방법 채택

Sequential consistency regularization loss

• 첫번째 padding token location (denoted by $N^{weak}$)에서 먼저 teacher’s sequential prediction을 prune하고,
• 각 글자들에 독립적으로 consistency regularization 적용

• 1(*>t) = threshold operator ⇒ teacher label의 신뢰도가 일정이상일 때만 학습에 반영
• L은 cross-entropy 또는 KL-divergence
• 6.2에선 threshold, label값 종류(prob vector or one-hot)의 영향에 대해서 실험

Teacher and Student Modalities

• 보통 teacher student decoder에서 consistency regularization을 계산하는 방법은 전체 네트워크의 단일 디코더를 통해서이지만,
• multimodal text recognition scheme에서는 각 modality가 각각의 decoder를 가지고 있으므로, 각각이 teacher 또는 student가 될 수 있음.
• 6.2에서는 각 configuration을 실험해 각 modality가 pseudo label을 생성하는 teacher가 되어야하는지 유무를 체크함

Experiments​

1. analyze capability of current synthetic and real-world datasets
2. compare our method with leading semi-supervised methods

Datasets

Comparison to State-of-the-Art Methods

Ablation Studies​

6.1 Vision Model Pretraining

Two-stage vs unified training

• 기존 contrastive learning ⇒ contrastive-based pretraining & fully-supervised fine-tuning 2 stages 였음
• contrastive learning objective와 supervised cross-entropy loss를 합치는 unified training stage로 진행

6.2 Consistency Regularization

Sequnetial consistency regularization loss

• cross-entropy vs KLDivergence
• soft label vs one hot label
• stopping the teach gradients and using a threshold

Teacher-student modalities

• 각 modality가 teacher 또는 student가 될 수 있는데, 각 modal끼리 teacher-student 관계가 가장 높은 성능을 보였다.

Conclusions and Future Work​

• SemiMTR은 첫번째 multimodal이자 semi-supervised learning 알고리즘을 사용한 text recognition 모델이다
• contrastive-based visual representation learning과 sequential, character-level consistency regularization을 적용했다.
• label 데이터 뿐만 아니라 unlabel 데이터도 활용하지만, 기존 모델의 3 스테이지를 그대로 유지했다.
• 다른 모델들보다 높은 성능을 보여준다
• 다른 리서처들에게 unlabel 데이터를 어떻게 활용할지에 대한 생각을 열어줬다.

11월 16일부터 3일간 카카오 if 2021이 열렸다. 개발자들에게 흥미로운 컨텐츠들로 가득했는데, 그 중 엔터프라이즈 팀에서 진행한 'OCR 모델 진행 개편기'가 눈에 들어왔다. 카카오는 OCR을 어떻게 구성하고 있을까? (OCR이 무엇인지 궁금하다면, 이 글을 읽어보길 권한다.)

OCR에 대한 설명과 카카오에서 구성하고 있는 OCR파이프라인을 소개했다. Text Detection과 Text Recognition 사이에 Script identification 을 두어 인식하는 이미지가 어떤 언어인지 구별한다고 한다. 이렇게 언어를 구별하는 단계를 두면, 언어별 특화된 모델 웨이트를 사용해서 더 광범위한 데이터 범위와 언어별 더 정확한 예측이 가능해진다.

그 후에, 인식한 단어들을 기반으로 해당 단어가 어떤 개체(entity; 사람, 조직, 시간 등 일반화할 수 있는 범주)에 속하는지 인식하는 NER(Named Entity Recognition) 과 텍스트 간 알맞게 묶어주는 Text Clustering , 그리고 등록된 템플릿에 단어들을 매칭하는 Template Matching 으로 후처리를 했다고 한다.

이 글은 어떻게 OCR 파이프라인을 AS-IS(현재 상태)에서 TO-BE로 개편하기 위해 어떤 점들을 고쳤는지에 대해 주목하고, 개편 전과 후의 모델 구조를 살펴보려고 한다.

(개인적으로 조금(보통은 1~2% 이내의) 나은 성능 향상을 위해 이미 성능이 어느정도 나오는 파이프라인을 과감히 놓아주고 새로운 체크포인트에서 출발을 하는 것은 결코 쉬운 일이 아니었을 거라고 생각한다. )

OCR 개편 목표​


새로운 시도를 위해 목표를 확실하게 정의하는 과정은 필수다. 텍스트 탐지 모델의 목표는 높은 정확도, 글자 레벨 박스, 모델을 통한 텍스트 클러스터링, 텍스트 방향 예측, 그리고 간단한 후처리였고, 텍스트 인식 모델의 목표는 마찬가지로 높은 정확도, 병렬 예측(더 빠른 연산을 위해서), 더 적은 리소스, 그리고 간단한 후처리였다고 한다. 그럼 텍스트 탐지 모델부터 어떤 식으로 개편했는지 알아보자.

텍스트 탐지 모델(STD)


AS-IS​

• 나열한 as-is 조건 중에 부합하는 모델 중 가장 유명한 모델은 아무래도 CRAFT인듯하다.

Object Detection

• 이미지 내에 물체의 영역을 탐지하는 물체 탐지 모델은 박스 좌표를 추출하는 방식에 따라, Segmentation-based와 Regression-based로 나뉠 수 있다.

1. Segmentation-based

• Segmentation-based는 원본이미지에 대응되는 Featuremap을 뽑아서 pixel 단위 처리로 물체 영역을 뽑는 방식이다.
• Segmentation-based Text Detction의 대표적인 모델, CRAFT는 적절한 파라미터 조절로 word-level과 character-level 텍스트 탐지가 가능하다.
• 아래 그림처럼 모델을 거친 각 글자들은 heatmap(아보카도처럼 생긴 동그라미)으로 표현된다. 정 가운데 빨강이 1에 가까운 값, 가운데에 멀어질수록 0에 가까운 파랑색 값을 갖게 된다. 이는 글자가 실제로 위치할 확률(probability)로도 해석이 가능하다.

[출처] : CRAFT: Character-Region Awareness For Text detection

• 뽑은 heatmap 위에 일정값 이상을 갖는 픽셀들끼리 합치고, 그 합친 영역을 구분하는 박스를 그리면 텍스트 영역 탐지가 완성된다.
• regression-based 방식처럼 박스 형태에 얽매이지 않고, pixel 단위로 텍스트 영역을 탐지하기 때문에 다양한 물체 형태를 예측 가능하다는 장점이 있다.
• 모델에서 나온 결과로부터 물체 영역을 탐지하는 후처리가 시간이 오래 걸린다는 단점이 있다.
• 한 이미지에 텍스트가 오밀조밀 모여 있을 가능성이 높은 문자 탐지 태스크의 특성상, segmentation-based 기법을 사용할 경우, 한 텍스트 그룹이 다른 텍스트 그룹과 겹치게 되는 경우가 생길 수 있다. 아래 그림처럼 'PLEASE', 'TURN', ... 등의 텍스트들은 개별의 텍스트 박스로 잡혀야 마땅하지만, heatmap 영역 간격이 가까우면 하나의 박스 형태로 잡히는 단점이 있다.


1. Regression-based

TO-BE​

• 그렇다면 to-be는?
• 조건별로 나열해서 모델을 추측해보자.
• TO-BE 조건들

  • one-shot anchor-free model

    • anchor free는 카카오에서 어떤 모델을 사용하는지 추측하는 데에 가장 큰 단서였다.
    • 물체 탐지(object detection) 모델은 크게 regression-based와 segmentation-based로 나뉜다.
    • regression-based는 다시 anchor-based와 anchor-free로 나뉜다. 그 중 anchor-based는 이미지 인풋을 격자 셀로 나누고, 각 격자마다 미리 정의해둔 k개의 앵커 박스들을 할당해서 물체의 박스 좌표를 표현한다.

      • 아래 그림을 예로 들면, 4x4 격자 셀에 2개의 앵커박스가 존재한다.

      • 박스 좌표는 보통 4개로 표현하기 때문에 아웃풋 형식은 4x4x(4*2)의 행렬이 된다.

      • 격자 셀 각각에 대해서 2개씩의 앵커박스, 그리고 각 앵커박스는 4개의 좌표로 구성

      • 한 격자 셀에 같은 클래스가 두 개 이상 존재하는 경우와 같은 앵커박스 형태가 두 개 이상 존재하는 경우는 이 anchor box구조가 커버하지 못하는 예외케이스이긴 하지만, 격자 셀 개수가 많아질수록 언급한 경우들을 드물다.

      • 학습을 위한 라벨링의 경우, 각 격자셀에 대해서 정답 박스 영역(gt box)과 앵커박스별 IoU를 구해서 positive 또는 negative, 아예 겹치지 않는 경우 background로 설정한다.

    

    • anchor-based detection는 사전정의된 앵커박스의 정보에 따라 성능이 바뀌는 문제와, 정확한 박스영역 탐지를 위해서는 더 많은 앵커박스가 필요하다는 문제, 그리고 각 그리드셀의 앵커박스 수만큼 (예: 50x50 grid x 80 anchor boxes=200k) gt를 포함하는지 안 하는지(positive인지 negative인지) IoU를 일일히 계산해야한다는 연산적 부담이 있다.
    • 이를 보완하기 위해 나온 것이 anchor-free model. anchor free의 대표적인 모델 FCOS(Fully Convolutional One Stage Object Detection) 모델을 살펴보자.

    FCOS

    	anchor-based	anchor-free
    격자 셀 라벨링	정답 박스와의 IoU 계산해서 positive 또는 negative 설정	정답 박스 안에 속하면 positive, 정답 박스가 여럿일 경우 ambiguous
    regression loss	L1 Loss	IoU loss
    classification loss	Binary Cross Entropy Loss	Focal Loss
    박스 좌표 regression 방법	anchor box와의 중심으로부터 박스값 보정	gt box 경계값으로부터의 거리

    • Centerness라는 개념 도입. heatmap과 유사
    • anchor based는 anchor box와의 offset을 계산하지만, FCOS는 중심점으로부터 거리를 계산한다.
    • L_cls는 focal loss, L_reg는 IoU loss
    • anchor box scale 대신 FCOS는 bounding box regression의 범위를 제한

  • Direct Regression

    • Indirect Regression은 앵커박스로부터 박스좌표를 보정하는 과정
    • Direct Regression은 중점으로부터 박스좌표를 바로 보정하는 과정
    • Segmentation-based에서 Direct Regression. 이는 박스를 구한 후, offset으로 박스 영역을 텍스트 영역에 좀 더 fit하게 깎는 과정이 있을 것 같다.

  • No NMS

    • Non-Maximum-Suppression을 빼고도 정확한 박스 후보군을 뽑을 수 있는 방법?

    • centerness라는 개념을 사용하면, 텍스트 영역 내의 모든 픽셀값이 다 같은 값을 갖는 것이 아니라, 중앙에 가까울수록 더 높은 값, 멀수록 더 낮은 값을 갖게 된다. min(l*, r*)와 max(l*, r*) 간 격차가 적다는 것은 중앙에 가깝다는 의미이다.

      

    • MT는 NMS 제거

  • Both Word & Character prediction

    

    • 사실 이 과정이 가장 궁금했다. CRAFT도 나온 heatmap으로부터 heatmap이나 affinity threshold를 조정하면 단어에서 글자 단위 탐색이 가능하지만, 정확하다고 하기엔 조금 무리가 있다.
    • Direct Regression이 character 단위로 결과를 뽑으면, offset으로 텍스트 영역을 깎는 과정에서 character들을 word로 합치는 과정이 있을 것 같다..?


• centerness
• offset
• regression

텍스트 인식 모델(STR)


AS-IS​

• CNN + Self-Attention + CTC
• NO TPS
• Variable Length Input
• Full Floating Point Precision

TO-BE​


• 이 구조는 사실 ViTSTR과 동일한 구조다.
• 한 가지 인상적이였던 것은 이미지 패치를 16x16이 아닌 텍스트 방향에 맞춰서 (보통 왼쪽에서 오른쪽으로 예상) column-wise하게 잘랐다는 점이다.
• STD 단계에서 orientation 방향을 구하는데, 이 값을 STR 단계에서 어떤 식으로 활용하는지 궁금하다.
  • 딱 떠오르는 방법은 orientation 방향에 맞게 왼쪽에서 오른쪽으로 회전.
• 듣고 보니 당연한 얘기인 것 같다.(훌륭한 논문의 개념을 다 읽고 나면, 마치 너무나도 당연해서 여태껏의 다른 방법들은 틀린 듯 느껴지는 것처럼)

학습 방법

STD​


• L1 Loss(예측값과 GT 차이를 절대값으로 계산) : 아마 STD에 들어가는 값 중, [Regression(박스 좌표), Offset] 에 사용될 듯

• BCE(Binary Cross Entropy Loss) : orientation과 centerness

• OHEM : Online Hard Example Mining의 약자. 학습 이미지의 픽셀 loss값 기준 임계값보다 큰 픽셀들을 hard sample, loss 값이 작은 픽셀들을 easy sample로 구별한다. negative pixel(easy sample) 양이 positive pixel의 양이 3배(조절 가능한 값)보다 많을 경우, negative pixel의 값은 전체가 아닌 top n개만큼(n < #negative pixel)만 반영한다.

  hard sample는 학습에 상대적으로 많이 반영하고, easy sample은 적게 반영한다는 컨셉.

  • OHEM이 사용된 예 (CRAFT)

    # 해당 코드는 [CRAFT-Reimplementation](https://github.com/backtime92/CRAFT-Reimplementation/blob/craft/loss/mseloss.py)에서 가져온 코드
    import numpy as np
    import torch
    import torch.nn as nn
    
    class Maploss(nn.Module):
        def __init__(self, use_gpu = True):
    
            super(Maploss,self).__init__()
    
        def single_image_loss(self, pre_loss, loss_label):
            batch_size = pre_loss.shape[0]
            # sum_loss = torch.mean(pre_loss.view(-1))*0
            # pre_loss = pre_loss.view(batch_size, -1)
            # loss_label = loss_label.view(batch_size, -1)
    
            positive_pixel = (loss_label > 0.1).float()
            positive_pixel_number = torch.sum(positive_pixel)
            positive_loss_region = pre_loss * positive_pixel
            positive_loss = torch.sum(positive_loss_region) / positive_pixel_number
    
            negative_pixel = (loss_label <= 0.1).float()
            negative_pixel_number = torch.sum(negative_pixel)
    
            if negative_pixel_number < 3*positive_pixel_number:
                negative_loss_region = pre_loss * negative_pixel
                negative_loss = torch.sum(negative_loss_region) / negative_pixel_number
            else:
                negative_loss_region = pre_loss * negative_pixel
                negative_loss = torch.sum(torch.topk(negative_loss_region.view(-1), int(3*positive_pixel_number))[0]) / (positive_pixel_number*3)
    
            # negative_loss_region = pre_loss * negative_pixel
            # negative_loss = torch.sum(negative_loss_region) / negative_pixel_number
    
            total_loss = positive_loss + negative_loss
            return total_loss
    
        def forward(self, region_scores_label, affinity_socres_label, region_scores_pre, affinity_scores_pre, mask):
            loss_fn = torch.nn.MSELoss(reduce=False, size_average=False)
    
            assert region_scores_label.size() == region_scores_pre.size() and affinity_socres_label.size() == affinity_scores_pre.size()
            loss1 = loss_fn(region_scores_pre, region_scores_label)
            loss2 = loss_fn(affinity_scores_pre, affinity_socres_label)
            loss_region = torch.mul(loss1, mask)
            loss_affinity = torch.mul(loss2, mask)
    
            char_loss = self.single_image_loss(loss_region, region_scores_label)
            affi_loss = self.single_image_loss(loss_affinity, affinity_socres_label)
            return char_loss + affi_loss
    

STR​


SeqSimCLR​

실제 라벨된 데이터로부터 Data Augmentation을 진행하면서 SeqSimCLR 기법을 사용했다고 한다.

SimCLR의 개념은 이렇다.

1. 인풋 이미지에 서로 다른 데이터 증강 기법을 적용한다. (예를 들어, 하나는 색 변환, 하나는 rotation)
2. 두 이미지를 네트워크에 태워서 Representation으로 표현한다.
3. 다시 조그만 네트워크에 태워서 Projections로 뽑은 후, Contrastive Loss로 유사도 손실함수로 계산한다.

![[출처] : https://zablo.net/blog/post/understanding-implementing-simclr-guide-eli5-pytorch/](Untitled 12.png)

https://deep-learning-study.tistory.com/731

seqfixmatch​

https://github.com/google-research/fixmatch

https://ainote.tistory.com/6

Reference

if(kakao) 2021 : OCR 모델 개편 진행기

Sequence-to-Sequence Contrastive Learning for Text Recognition

PlugNet: Degradation Aware Scene Text Recognition Supervised by a Pluggable Super-Resolution Unit

AE TextSpotter: Learning Visual and Linguistic Representation for Ambiguous Text Spotting

MT: Multi-Perspective Feature Learning Network for Scene Text Detection

What's wrong with the Bottom-up Methods in Arbitrary-shape Scene Text Detection?

https://neverabandon.tistory.com/m/60