https://www.amazon.science/publications/cash-transaction-booking-via-retrieval-augmented-llm
문제가 생소하기는 하지만 적절한 솔루션을 잘 설명해줘서 (그리고 단계단계 rationale을 잘 공유해줘서) 읽으면서 재밌었던 페이퍼.
일단 문제를 설명하면 저 Transaction Description를 입력받아서 (a) GL-account를 찾아야 하고, (b) 동시에 Search String도 추출을 해야 한다.
솔루션으로는 metric learning을 해가지고 Transaction 인코더를 잘 만들고, 그걸 가지고 nearest neighbor를 찾는다.
(a) 지금 인덱스 되있는 neighbor들은 이미 GL-account가 있을테니 그걸 가지고 majority voting을 한다.
(b) 또 neighbor들의 Search String extraction 결과를 가지고 LLM에다가 예시를 줘가면서 String extraction을 시킨다.
기억에 남는 부분 1
(a) GL-account를 찾는 부분에서 classifier를 만들지 않고, encoder를 만들어서 임베딩 유사도를 이용해서 GL-account를 찾는 이유 설명이 좋았다.
- 일단 encoder를 만들어 놓으면 나중에 nearest neighbor 찾아서 (b)의 인풋으로 넣을 때 재활용 할 수 있다
- 새로운 GL-account가 생겼을 때 대응이 훨씬 잘 된다 (classifier는 다시 훈련해야 함)
기억에 남는 부분 2
요즘 과연 어느 모델 부터가 흔히 사람들이 생각하는 다재다능한 LLM일까..하는 생각을 하는데 이 String extraction task 에서는
Bloom-176B / Alexa-20B / FLAN-T5-XXL (11B) / FLAN-UL2 (20B) 정도가 의도한대로 작업을 할 수 있었다고 한다. 그 이하 모델은 아예 사용이 불가했다고.
