용량과 속도 최적화
이전 포스팅대로 인풋의 방향성을 잡은 다음 인풋을 넣어 튜닝해 기록해보니 와인 데이터 10개의 용량이 2.1MB나 되는걸 확인했다. 7000건 정도의 와인 데이터가 있으니 다 한다면 14000MB가 될 수도 있어 문제가 많았다.
그리고 추천을 위해 와인을 조회하는 속도도 문제가 있었다. 와인 정보를 DB에서 불러와서 맛, 타입, 향기, 가격등을 전부 Embedding으로 변환하는 과정까지 거치다 보면 시간도 오래 걸렸다. 임의로 돌렸을 때는 Embedding 으로 변환하는 시간만 2분, 추천 로직에 또 2분씩 걸리고 아주 난리였다.
이대론 안되겠다 싶어 인풋 튜닝을 새롭게 해서 파일 입출력으로 재사용을 하기로 했다.
재사용
지난 포스팅에서 기존 설계였던 인풋은 다음과 같다.
input1: "1, 1, 1, 1, RED, {[시트러스], [열대과일, 파인애플], 아카시아, 꽃], [미네랄], [꿀]}, 100000, 알바리뇨"
input2: "3, 1, 3, 1, RED, {[시트러스], [파인애플], [아카시아], [미네랄], [꿀]}, 500000, 알바리뇨"
"similarity": 0.9150122442827834하지만 이 값들 중에선 겹치는 부분이 많고 다른 와인 7000건 내에서도 충분히 겹칠 여지가 많았다.
그래서 없앴던 Key값을 다시 부활시키고 문자열 하나였던 인풋을 전부 분리하기로 했다.
0 = "sweetness:3"
1 = "acidity:2"
2 = "body:2"
3 = "tannin:1"
4 = "type:WHITE"
5 = "price:65000"
6 = "lemon:시트러스"
7 = "pineapple:열대과일"
8 = "pineapple:파인애플"
9 = "flower:아카시아"
10 = "flower:꽃"
11 = "stone:미네랄"
12 = "ripen:꿀"이렇게 해서 와인 하나를 불러올 때 13번의 Embedding 변환이 일어나고, 이 인풋을 Key로 사용해서 Value에 변환한 Embedding을 파일입출력으로 저장해 재사용하는 방식을 취했다.
향기는 그나마 와인마다 다른 값이 많았지만 맛, 타입, 가격같은 데이터는 중복이 많아 최적화가 꽤 잘되었다.
이후 다른 와인의 경우에도 이런식으로 분리해서 전부 확인한 결과 Embedding 파일의 크기가 점점 작아지게 되었다.
sweetness:3: [1536차원]
acidity:2: [1536차원]
body:2: [1536차원]
tannin:1: [1536차원]
type:WHITE: [1536차원]
price:65000: [1536차원]
aroma_lemon:시트러스: [1536차원]
aroma_pineapple:열대과일: [1536차원]
aroma_pineapple:파인애플: [1536차원]
aroma_flower:아카시아: [1536차원]
aroma_flower:꽃: [1536차원]
aroma_stone:미네랄: [1536차원]
aroma_ripen:꿀: [1536차원]
sweetness:1: [1536차원]
acidity:3: [1536차원]
price:46000: [1536차원]
aroma_apple:배: [1536차원]
aroma_herbal:허브: [1536차원]
body:3: [1536차원]
tannin:2: [1536차원]
type:RED: [1536차원]
price:50000: [1536차원]
aroma_berry:체리: [1536차원]
aroma_berry:딸기: [1536차원]
aroma_berry:라스베리: [1536차원]
aroma_apple:자두: [1536차원]
aroma_cinnamon:후추: [1536차원]
aroma_cinnamon:바닐라: [1536차원]어찌저찌 여기까지 와서는 쓸만한 로직이 되었다고 생각했지만 완전 오판이었다. 인풋 튜닝은 다음에도 이어지게 됐다.
