AI 모델과 AI 시스템은 무엇이 다른가

AI 모델과 AI 시스템은 무엇이 다른가

• 모델은 학습으로 만들어진 결과물이다. 구조와 그 안을 채우는 숫자들, 즉 파라미터의 덩어리다. 파일로 저장하고 복사하고 옮길 수 있다.

• 시스템은 그 모델을 감싸서 실제로 쓸 수 있게 만든 전체다. 입력을 받아 정리하고, 모델에 넣고, 나온 결과를 걸러내고, 화면에 보여주고, 문제가 생기면 알리는 것까지 포함한다.

한 문장으로 줄이면 이렇다.

모델은 시스템의 일부이고, 대개 가장 작은 부분이다.

우리가 실제로 쓰는 것은 모델이 아니라 시스템이다. 챗봇 서비스를 쓸 때 만나는 것은 모델 파일이 아니라 그것을 감싼 제품이고, 그 제품이 어떻게 만들어졌느냐에 따라 같은 모델도 완전히 다르게 다가온다.

용어 주의 — 여기서 말하는 '시스템'은 컴퓨터 운영체제나 전산 시스템을 뜻하는 것이 아니다. 하나의 목적을 위해 함께 동작하는 부품들의 묶음 정도의 뜻이며, 모델은 그 부품 중 하나다.

둘은 종류가 다르다

크기 차이보다 먼저 짚을 것이 있다. 모델과 시스템은 같은 것의 작은 버전과 큰 버전이 아니다. 성격 자체가 다르다.

모델은 함수에 가깝다. 입력을 받아 계산해서 출력을 내놓는다. 같은 파라미터에 같은 입력을 넣으면 계산 결과가 같다. 기억하지 않고, 순서를 따지지 않고, 바깥에 무언가를 남기지 않는다.

시스템은 과정에 가깝다. 상태를 들고 있고, 순서가 있고, 바깥에 영향을 남긴다. 대화 기록을 저장하고, 어제 한 요청과 오늘 한 요청을 잇고, 로그를 쌓고, 누군가에게 알림을 보낸다.

이 차이가 실질적인 결과를 만든다. 모델은 무엇을 계산하는지만 물으면 되지만, 시스템은 무엇을 계산하는가에 더해 무엇을 기억하고 무엇을 남기는지까지 물어야 한다. 개인정보에 관한 질문이 대개 시스템 쪽 질문인 이유가 여기 있다.

경계는 어디인가

둘 사이의 경계가 어디인지에 대해 합의된 답이 없다.

애매한 자리를 몇 개 보면 왜 그런지 알 수 있다.

토크나이저. 텍스트를 토큰이라는 조각으로 자르는 규칙이다. 모델과 함께 만들어지고 함께 배포되며, 다른 것으로 바꾸면 모델이 제대로 동작하지 않는다. 그런데 학습으로 정해진 파라미터는 아니다. 모델인가 시스템인가.

뽑는 단계. 언어 모델이 실제로 내놓는 것은 다음에 올 후보들의 확률 분포이고, 거기서 하나를 골라내는 단계가 그다음에 온다. 이 단계를 어떻게 설정하느냐에 따라 같은 모델이 매번 다른 답을 내놓기도 하고 늘 같은 답을 내놓기도 한다. 결과를 크게 좌우하는데 모델의 계산 바깥에 있다.

앞에 붙는 지시문. 사용자가 무엇을 입력하든 그 앞에 항상 붙는 문장들이 있다. 모델의 태도와 말투를 크게 바꾸지만 파라미터를 건드리지는 않는다.

이 자리들을 어느 쪽으로 세느냐는 문맥에 따라 달라진다. 그래서 "모델"이라는 말이 대화마다 다른 범위를 가리킬 수 있다.

여기서 실용적인 기준 하나가 나온다.

파일로 저장해서 남에게 보냈을 때 함께 가는 것인가, 아니면 그 파일을 받은 사람이 새로 만들어야 하는 것인가.

파라미터는 함께 간다. 필터 규칙과 검색 대상 문서와 화면 구성은 함께 가지 않는다. 토크나이저는 대개 함께 가고, 뽑는 방식의 설정값은 대개 받는 쪽이 새로 정한다.

완벽한 기준은 아니지만, 어떤 글이 "모델"이라 할 때 어디까지를 뜻하는지 가늠하는 데 쓸 만하다.

모델은 시스템에서 얼마나 작은가

크기 이야기로 돌아가면, 실측한 자료가 있다.

2015년에 구글 연구자들이 쓴 논문이 이 문제를 정면으로 다뤘다. 이들이 관찰한 흐름은 이랬다.

ML 시스템을 개발하고 배포하는 것은 상대적으로 빠르고 싸지만, 시간이 지나며 유지하는 것은 어렵고 비싸다.

같은 논문이 학계 독자에게 놀라울 수 있다며 짚은 사실이 있다. 많은 ML 시스템에서 실제로 학습이나 예측에 쓰이는 코드는 극히 일부이며, 나머지 상당 부분은 '배관 작업'이라 부를 만한 것이라는 지적이다.

논문의 대표 그림에 붙은 설명이 이 논지를 요약한다. 실제 ML 시스템에서 ML 코드가 차지하는 비중은 가운데의 작은 검은 상자만큼이고, 그것을 둘러싸는 데 필요한 인프라는 방대하고 복잡하다.

그리고 논문은 이것을 숫자로도 적었다. 성숙한 시스템은 결국 많아야 5%가 머신러닝 코드이고 적어도 95%가 그것을 잇기 위한 코드가 될 수 있다는 것이다.

이 숫자를 정확히 읽을 필요가 있다. 모델이 덜 중요하다는 뜻이 아니다. 모델이 없으면 나머지 95%는 존재할 이유가 없다. 다만 모델을 만드는 일과 AI 제품을 만드는 일이 같은 크기의 일이 아니라는 뜻이다.

시스템의 행동은 모델의 행동으로 환원되지 않는다

부품을 다 알면 전체를 알 수 있을 것 같지만, 이 분야에서는 그렇지 않다는 것이 반복해서 관찰되었다.

같은 2015년 논문의 지적이 이 점을 짚는다. 모델이 여러 입력 신호를 섞어 쓰기 때문에 개선을 따로 떼어내기가 불가능하다는 것이다. 어떤 특징의 입력 분포를 바꾸면 나머지 모든 특징의 중요도와 가중치와 쓰임새가 함께 바뀔 수 있다. 특징을 새로 넣거나 빼도 마찬가지다.

논문의 문장이 단호하다. 어떤 입력도 정말로 독립적이지 않다. 그래서 이 원칙에 이름을 붙였다.

CACE 원칙 — 무엇을 바꾸든 전부가 바뀐다(Changing Anything Changes Everything).

그리고 이것이 입력 신호에만 해당하는 것이 아니라 하이퍼파라미터, 학습 설정, 표본 추출 방법, 수렴 기준, 데이터 선택 등 생각할 수 있는 거의 모든 조정에 적용된다고 적었다.

여기서 얻을 개념적 결론이 있다. 부품을 하나씩 잘 만든다고 전체가 잘 되는 것이 아니다. 그래서 모델을 개선했는데 시스템 전체 성능이 나빠지는 일이 생기고, 시스템은 부품의 합이 아니라 별도로 평가해야 하는 대상이 된다.

평가의 단위가 다르다

앞의 결론에서 자연스럽게 따라 나오는 것이 있다. 모델을 재는 방법과 시스템을 재는 방법이 다르다.

모델은 벤치마크로 잰다. 정해진 문제 묶음을 넣고 몇 개를 맞혔는지 센다. 다른 모델과 같은 조건에서 비교할 수 있다는 것이 장점이다.

시스템은 그렇게 잴 수 없다. 사용자가 원하는 것을 얻었는지, 얼마나 기다렸는지, 잘못된 답을 받았을 때 알아챌 수 있었는지 같은 것들은 문제 묶음으로 환원되지 않는다.

그래서 벤치마크 점수가 높은 모델을 썼다는 것이 좋은 제품이라는 뜻은 아니다. 반대로 어떤 제품이 만족스럽다고 해서 그 안의 모델이 가장 좋은 모델인 것도 아니다. 둘은 다른 자를 쓴다.

같은 모델이 다른 제품이 된다

지금까지의 이야기가 하나로 모이는 지점이 여기다.

같은 모델을 가져다 써도, 그것을 감싼 시스템이 다르면 사용자가 겪는 것은 완전히 달라진다. 어떤 문서를 찾아 넣어주는지, 어떤 지시를 앞에 붙이는지, 어떤 응답을 막는지, 대화 기록을 얼마나 들고 있는지가 전부 시스템 쪽 결정이기 때문이다.

파운데이션 모델을 다룬 2021년 스탠퍼드 보고서도 같은 점을 강조한다. 이 보고서는 모델을 만드는 훈련 단계가 연구에서 각광받는 중심이지만 여러 단계 중 하나일 뿐이라고 적으며, 데이터 생성부터 배포까지를 하나의 생태계로 보라고 권한다.

특히 배포를 위한 적응 단계에 대한 서술이 이 글의 논지와 정확히 겹친다. 배포를 위한 적응은 여러 모듈, 맞춤 규칙, 별도의 분류기, 다른 신호와의 결합을 필요로 하며, 그래서 유해한 내용을 생성할 수 있는 문제적 모델이라도 하류에서 적절한 예방 조치를 취하면 감당할 수 있을지 모른다는 것이다.

같은 보고서가 명시한 또 하나가 있다. 배포는 구성과는 별개의 결정이다. 모델을 만들었다는 것과 그것을 사람들에게 내놓는다는 것은 서로 다른 판단이라는 뜻이다.

그래서 이 구분이 무엇을 판단하게 해주는가

이 구분의 값어치는 세 가지 질문에 답할 수 있게 된다는 데 있다.

무엇이 잘못됐을 때 어디를 보는가. 모델이 학습 데이터에 없던 상황을 만난 것인지, 아니면 검색이 엉뚱한 문서를 가져왔거나 필터가 과했거나 지시문이 잘못 쓰인 것인지는 완전히 다른 문제다.

가늠하는 방법이 하나 있다. 같은 질문을 같은 모델을 쓰는 다른 서비스에 넣어보는 것이다. 여러 곳에서 비슷하게 나온다면 모델 쪽일 가능성이 크고, 한 곳에서만 그렇다면 그 서비스가 모델 주변에 무엇을 얹었는지를 의심해야 한다.

내가 준 정보가 어디까지 가는가. 모델은 추론 시점에 파라미터가 고정되어 있으므로 내 입력이 모델을 바꾸지 않는다. 그런데 시스템은 대화를 저장할 수 있고, 저장한 것을 나중에 학습에 쓸 수도 있다. "이 AI가 내 말을 기억하나요"는 모델 쪽 질문처럼 들리지만 실제로는 시스템 쪽 질문이다.

누구의 결정이 그 결과를 만들었는가. 모델을 만든 곳과 그것을 감싸 제품으로 내놓은 곳이 다른 경우가 많다. 어떤 답이 걸러졌다면 그것은 모델의 성질일 수도 있고 그 위에 얹은 필터의 결정일 수도 있다. 어느 쪽 결정인지를 가려야 무엇을 문제 삼을지도 정해진다.

흔한 오해

"AI를 쓴다는 것은 모델을 쓴다는 뜻이다." 우리가 실제로 쓰는 것은 모델을 감싼 시스템이다. 모델은 그 안의 한 부품이며, 실제 시스템에서 학습과 예측에 쓰이는 코드는 극히 일부다.

"모델과 시스템의 경계는 명확하다." 합의된 답이 없다. 토크나이저, 확률에서 하나를 뽑는 단계, 앞에 붙는 지시문 같은 자리들은 문맥에 따라 어느 쪽으로도 셀 수 있다. 그래서 "모델"이라는 말이 글마다 다른 범위를 가리킬 수 있다.

"모델이 좋으면 제품도 좋다." 같은 모델이라도 어떤 문서를 넣어주는지, 어떤 지시를 앞에 붙이는지, 어떤 응답을 거르는지에 따라 사용자가 겪는 것이 완전히 달라진다.

"제품이 이상하면 모델이 나쁜 것이다." 모델은 멀쩡한데 검색이 엉뚱한 문서를 가져왔거나 필터가 과할 수 있다. 같은 모델을 쓰는 다른 서비스에서도 같은 문제가 나오는지 보면 어느 쪽인지 가늠할 수 있다.

"벤치마크 점수가 높은 모델을 쓰면 좋은 제품이 된다." 모델과 시스템은 다른 자로 잰다. 벤치마크는 정해진 문제 묶음을 맞히는지를 재고, 시스템은 사용자가 원하는 것을 얻었는지를 재야 한다.

"부품을 하나씩 개선하면 전체가 좋아진다." 2015년 논문은 어떤 입력도 정말로 독립적이지 않으며 하나를 바꾸면 나머지가 함께 바뀐다고 지적했다. 개별 부품을 개선했는데 전체 성능이 나빠지는 경우가 있다.

"모델이 답한 것이니 그 회사의 판단이다." 모델을 만든 곳과 그것을 감싸 제품으로 내놓은 곳이 다른 경우가 많다. 어떤 답이 걸러졌다면 모델의 성질일 수도 있고 그 위에 얹은 필터의 결정일 수도 있으며, 둘은 서로 다른 곳의 결정이다.

확인한 자료

• Sculley, D., Holt, G., Golovin, D. et al., Hidden Technical Debt in Machine Learning Systems, Advances in Neural Information Processing Systems 28, 2503–2511, 2015 — 논문 전문. ML 시스템의 개발과 배포는 빠르고 싸지만 유지는 어렵고 비싸다는 관찰, 이 부채가 코드 수준이 아니라 시스템 수준에 존재해 발견하기 어렵다는 지적, 많은 ML 시스템에서 학습이나 예측에 쓰이는 코드가 극히 일부이며 나머지는 '배관 작업'이라는 서술과 그림 1의 설명, 성숙한 시스템이 많아야 5% 머신러닝 코드에 적어도 95% 글루 코드가 될 수 있다는 추정, 그리고 어떤 입력도 정말로 독립적이지 않다는 얽힘 논의와 CACE 원칙의 정의 및 적용 범위.

• Bommasani, R., Hudson, D. A., Adeli, E. et al., On the Opportunities and Risks of Foundation Models, arXiv:2108.07258, Center for Research on Foundation Models, Stanford HAI, 2021 — 서론 및 §1.1.1. 훈련이 연구에서 각광받는 중심이지만 여러 단계 중 하나일 뿐이라는 지적, 데이터 생성·데이터 큐레이션·훈련·적응·배포로 이루어진 생태계 구분, 배포를 위한 적응이 여러 모듈과 맞춤 규칙과 별도의 분류기와 다른 신호와의 결합을 요구한다는 서술, 유해한 내용을 생성할 수 있는 문제적 모델이라도 하류에서 적절한 예방 조치를 취하면 감당할 수 있을지 모른다는 예시, 그리고 배포가 구성과는 별개의 결정이라는 명시.