AI모델^[1]은 가면 갈 수록 강력해지고 작업을 더 많이 할 수 있게 됐다.
그리고 AI모델에 대한 접근성도 (아직은)합리적인 가격으로 사용할 수 있게 됐다. 이를 통해 AI를 활용해서 앱을 만드는 것이 매우 수월해졌다.

AI 애플리케이션에 대한 진입장벽 또한 낮아졌다. 기존 ML모델을 깎아쓰던 때에 비해 훨씬 쉬워졌다는 것을 말한다. 앞서 말한 모델을 쓰면 되니까.

ML모델 기반으로 만드는 건 개빡인데 파운데이션 모델을 쓰면 전에 비해 전혀 새로운 접근방식과 허들이 생긴다. 그와 동시에 AI 엔지니어가 기존 ML 엔지니어와 어떤 식으로 역할이 달라지는가도 볼 수 있다.

AI 엔지니어링의 부상

파운데이션 모델은 언어모델에서 출발했다. 첫 언어모델은 1950년도에 등장했고, 어떤 식으로 발전되었나 살펴보자.

언어 모델에서 LLM으로

언어 모델은 옛날부터 있었지만 자기 지도 학습(self-supervised learning) 덕에 언어 모델은 지금과 같이 성장할 수 있었다.

언어 모델

언어 모델(language model)은 하나 이상의 언어에 대한 통계 정보를 인코딩한다. 언어의 통계적 특성을 가지고 모델링하는 연구가 계속 이어져왔다. 그 중 하나가 클로드 섀넌의 〈Prediction and Entroyp of Printed English〉 라는 논문이다. 이 논문에서 소개된 엔트로피 등의 개념이 요즘의 언어 모델링에도 쓰이고 있다.

언어 모델은 한 언어만 다루었다가 요즘은 여러 언어도 다룰 수 있게 되었다.

언어 모델의 기본 단위는 토큰이다. 토큰은 모델에 따라 문자, 단어, 단어의 일부가 될 수 있다. 각 모델별로 텍스트를 토큰화하는 건 공개되어있거나 비공개다.

토큰화(tokenization)는 원문을 모델이 정한 길이로 나누는 과정을 말한다. GPT-4 기준, 하나의 평균 길이는 단어의 ¾정도다. (e.g., 100토큰 - 75개 단어)

모델이 다룰 수 있는 모든 토큰의 집합은 어휘(vocabulary)라고 한다. 알파벳 몇개로 단어를 만들 수 있는 것 처럼 소수의 토큰 만으로 많은 고유단어를 만들 수 있다. 토큰화 방법과 어휘 크기는 모델 개발자가 별도로 결정한다.

아래는 어휘 크기의 예시다:

• Mixtral 8x7B - 32000개
• GPT-4 - 100256개

언어 모델은 두 종류가 있다.

1. 마스크 언어 모델(masked language model)
   • 누락된 토큰 전후 컨텍스트를 사용해 시퀀스의 어느 위치든 토큰을 예측하도록 학습한다.
   • 빈칸 채우기를 학습한다. (E.g., '내가 좋아하는 _ 은 파란색이다')란 컨텍스트에서 빈칸에 색상 을 예측하도록 하는 것이다
   • 감정 분석, 테스트 분류 등 신규 텍스트를 만들지 않은 작업에 주로 쓰인다.
   • 코드 디버깅 등 앞뒤 코드를 보고 이해하여 오류를 찾는 전체 컨텍스트 이해작업에도 쓰인다
   • 예시: BERT
2. 자기회귀 언어 모델(autoregressive language model)
   • 이전 토큰들만 보고 시퀀스의 다음 토큰을 예측하도록 학습한다. (E.g., '내가 가장 좋아하는 색상은 _ 이다' 에서 빈칸에 뭐가 올지 예측한다)
   • 토큰을 하나씩 순차적으로 생성할 수 있다

이 책에서는 별도 명시 없으면 언어모델은 자기회귀 모델을 의미한다.

또한 언어모델의 출력에는 제한이 없다. 정해진 유한 어휘를 이용해서 무한한 결과물을 만들어낼 수 있다. 이렇게 정해진 답 없이 개방형 출력을 생성하는 모델을 생성 모델(generative model)이라 한다. 여기서 생성형 AI(generative AI)라는 말이 나왔다.

언어모델은 텍스트(프롬프트가)가 주어지면 이에 답을 완성하려는 완성 기계(completion machine)에 가깝다. 이를테면,

>>> 	"사느냐 죽느냐"
Out[1]  ", 그것이 문제로다."

그렇지만 이는 확률에 기반한 예측이며, 정확성을 보장하지 않는다. (2장에서 더 살펴보도록 한다)

언어 모델의 완성능력은 번역, 요약, 코딩, 수학문제 풀이 등을 완성할 수도 있다. 심지어는 질의에 응답을 완성하는 식으로의 역할을 할 수도 있다.
완성능력은 좋지만 대화를 하는 것과 같지는 않다. 언어모델에 질의를 하면, 답 대신 또 다른 질의로 문장을 완성할 수도 있다. 사용자의 요청에 적절히 응답하도록 하는 대처는 [[2.3 사후학습]] 절에서 확인하도록 한다.

자기 지도 학습

언어 모델링은 수많은 ML 알고리즘 중 하나이다. 언어 모델링 말고 객체 탐지, 토픽 모델링, 추천 시스템, 일기 예보, 주가 예측 등에 대한 모델도 있다. 그럼에도 규모 확장 접근법의 핵심이 된 이유는 아래와 같다.

다른 모델들은 지도학습(supervised learning)을 필요로 하지만, 언어 모델은 자기 지도 학습(self-supervised learning)으로 학습할 수 있다.

지도학습

• 레이블이 있는 데이터로 ML 학습함
• 학습해야 할 행동을 보여주는 예시에 레이블을 달고, 이 예시로 모델을 학습함. 학습 후 새 데이터에 모델을 적용할 수 있음
• 비용과 시간소모가 큼. (E.g., 데이터 레이블링은 작업의 복잡성, 규모에 따라 천차만별로 달라짐)
• 모델의 기능을 좀 더 잘하게끔 확장하려면 더 많은 범주의 레이블이 추가되어야 함
  • 쉬운 건 어떻게든 하겠지만
  • 어려운 학습에 대한 지도학습은 데이터가 좋은지/레이블이 잘 달려있는지 등이 더 어려울 것임

자기 지도 학습

• 레이블링 병목 현상을 극복함
• 모델이 학습할 수 있는 더 큰 데이터셋을 만들 수 있음
  → 모델크기 확장 가능
• 명시적인 레이블 없이 모델이 입력 데이터에서 레이블을 추론할 수 있음
• 언어 모델링은 각 입력 시퀀스가 레이블(예측할 토큰)과 모델이 이 레이블을 예측하는 데 사용할 수 있는 컨텍스트를 모두 제공함
  → 자기 지도 학습이 가능
• 이 시퀀스에 대한 시작/끝점 처리가 매우 중요함(사람이 말을 언제 끊어야 하는 지 아는 것 처럼)

자기 지도 학습은 언어 모델이 레이블링 없이도 텍스트 시퀀스를 통해 학습할 수 있다. 책, 블로그 게시물, 기사, 댓글, 논문 등등 뭐든 다 읽을 수 있으니 엄청난 양의 데이터를 구축할 수 있고, 이 모델이 그래서 LLM이 될 수 있다.

그런데 그 대규모(large)가 어느정도여야 되는 것일까? 이는 파라미터 수로 측정된다. 파라미터는 학습 과정을 통해 업데이트되는 ML 모델 내의 변수다^[2]. 모델의 파라미터가 많을 수록 원하는 행동을 더 잘 학습할 수 있다. 꼭 그런건 아니다.

2018년 6월 GPT가 처음 나왔을 때는 117,000,000 개의 파라미터를 가지고 있었다. 2019년 2월 GPT-2는 1,500,000,000 개의 파라미터를 갖추었다. 2024년 기준은 1000억개의 파라미터가 대규모로 지칭된다. 변화가 빠르므로 저 '대규모'는 작은 게 될 수도 있다.

더 큰 모델은 왜 더 많은 데이터를 요구할까? 모델이 크면 학습을 많이 할 수 있으니, 성능이 좋아지려면 그 만큼의 학습 데이터가 필요하다^[3]. 큰 모델을 작은 데이터셋으로 학습하면 자원이 아까우니까. 모델을 극대화하는 움직임이 대세라면 계속해서 이런 식으로 성능을 불리려는 시도가 이어지는 것이다. 데이터셋이 작으면 더 작은 모델을 써도 비슷하거나 더 나아질테니까.

대규모 언어 모델에서 파운데이션 모델로

앞서 언어 모델의 강력함을 보았지만, 글에만 한정되어 있었다. 따라서 AI가 유용하게 쓰이려면 글자 이상의 데이터를 처리하는 능력을 요구한다. (시각, 청각, 촉각(??) 등)

언어 모델은 이런 점에서 많은 데이터 모달리티를 포함하도록 확장하고 있다.

• 클로드 3는 이미지, 텍스트를 이해할 수 있다
• 일부 모델은 동영상, 3D 애셋, 단백질 구조 등을 이해할 수 있다
• 2023년 GPT-4V 는 다양한 모달리티를 LLM에 통합하는걸 주요 기조로 언급했다.

그러다보니 이 LLM을 파운데이션 모델로 지칭하기도 한다. 다시말해 이 모델들이 AI 애플리케이션에서 갖는 중요상과 다양한 요구사항에 맞게 발전시킬 수 있다는 것을 의미한다(2장에서 다시 볼 예정)

파운데이션 모델은 기존 구조에 변화를 가져왔다. 본래는 자연어 처리, 컴퓨터 비전, 오디오 처리 등등을 각각 독립적으로 처리되었다.

둘 이상의 데이터 형태를 처리할 수 있는 모델을 멀티모달 모델이라고 한다. 생성형 멀티 모달 모델은 LMM(large multimodel model)이라 부르기도 한다. 글자토큰, 이미지 토큰을 모델에 넣어 다음 토큰을 만드는 식이다.

멀티모달도 규모 확장을 위해선 데이터가 필요하고, 자기 지도 학습은 멀티모달 모델에서도 효과가 있다. 오픈AI는 '자연어 지도(natural language supervision)'이란 자기지도 변형으로 이미지 모델 CLIP(OpenAI, 2021)을 학습했다. 이미지/텍스트 쌍으로 학습하여 수동 레이블링없이 수백배 더 큰 이미지 분류작업을 완료했다.

단 CLIP은 생성모델이 아닌 임베딩 모델(embedding model)이다. 텍스트와 이미지를 함께 임베딩 하도록 구성되어있다([[3.3.3 임베딩 소개]] 참조). 이런 CLIP같은 멀티모달 임베딩 모델은 Flamingo, LLaVA, Gemini(previously Bard)같은 생성형 멀티 모달의 핵심이다.

이렇다보니 파운데이션 모델은 범용 모델로 전환하는 것을 의미한다. 전과 다르게 규모와 학습방식으로 인해 다양한 작업을 함께 수행할 수 있도록 구성되어 있다. 이럴 때 특정 작업의 성능을 올리려면 파인튜닝(fine-tuning)을 한다.

파운데이션 모델은 정말 많은 작업을 할 수 있고, 그 종류는 Super-NaturalInstructions 벤치마크(Wang et al., 2022)^[4] 에서 볼 수 있다.

예를들어 특정 도메인에서 앱 하나를 개발한다 쳤을 때, 상용 모델은 그냥 뻔한소리만 하는 등 결과물이 만족스럽지 않을 수 있다. 개선법은 아래와 같다:

• 모델이 원하는 결과물을 내놓도록 상세한 지시를 모델에 제공하여 답변을 유도하는 방법이 있다. 이 접근법이 프롬프트 엔지니어링(prompt engineering)이다.
• 모델을 고객 리뷰 DB에 연결해서 더 나은 설명을 생성하도록 할 수도 있다. 이 접근법이 검색 증강 생성(RAG, Retrieval-augmented Generation)이다.
• 고품질 제품 설명 데이터셋을 이용하여 모델을 추가로 파인튜닝할 수도 있다.
  이런 기법이 대표적인 AI 엔지니어링 기법이다.

특정 작업용 모델을 만드는 것 보단 훨씬 쉽다. 그렇지만 작업에 특화된 모델도 장점이 있다. 모델이 작으니, 빠르고 저렴하게 쓸 수 있다는 것이다. 이런식의 트레이드오프를 알고 잘 선택하자.

파운데이션 모델에서 AI 엔지니어링으로

예전에도 ML 모델 깎아서 앱을 많이 만들어왔고, 그런 과정이 ML 엔지니어링 혹은 MLOps 라고 불리었다. 요즘은 AI 엔지니어링이란 표현을 함께 쓴다.

모델 자체를 깎는 게 기존 ML 엔지니어링식 접근법이었다면 이미 있는 모델을 잘 쓸 수 있도록 하는 것이 AI 엔지니어링이다. 강력한 파운데이션 모델을 편히 쓸 수 있는 것은 AI 엔지니어링의 빠른 성장을 위한 세 요인이다.

1. 범용 AI능력
   • 많은 걸 할 수 있고 능력이 뛰어나다
   • 이것 만으로 고객이 원한 니즈를 채워줄 수 있다
2. AI 투자 증가
   • AI 앱 구축 비용이 줄고 출시속도가 빨라지니까 투자가 많이 일어난다
   • 요새도 그렇긴하지
3. AI 애플리케이션에 대한 낮아진 진입장벽
   • 단일 API로 강력한 모델에 접근할 수 있다
   • "자연어"로 "코드 작성"을 할 수 있게 되었다

이런 파운데이션 모델 개발은 대규모의 자본에서 나온다. 이런 건 아직 큰 기업이나 국가차원, 혹은 초엘리트들이 비일비재한 스?타트업에서 이루어지고 있다.

파운데이션 모델 활용 사례

내가 생각할 수 있는 모든 것들, 아니 모든 사람이 생각할 수 있는 한계가 곧 모델 활용의 한계다. 즉 무한하다.

이번에 외주를 수주한 것도 사실 다이렉트로 여기 해당된다. 내가 하는 파트는 12.7%나 차지한다. 심지어 오픈소스인데도...

그리고 기업은 내부 지향적 애플리케이션을 훨씬 빨리 도입한다. 실패요소를 최소화하면서(데이터 프라이버시, 규정 준수, 잠재적 치명 실패), AI 엔지니어링 전문성 강화에 도움이 될 수 있다.

코딩

진짜 수많은 도구가 있다. 말하기도 아플정도.

• 프레임워크 전환
• 데이터 추출
• 자연어를 코드로
• 커밋 메시지를 만들고
• 테스트코드도 짜고
  ...예시만 봐도 진짜 흔히 생각할 수 있는 모든 일이다.

이미지 및 동영상

AI로 이미지, 영상 생성하는 사례는 이미 말할 것도 없다.
아래에서 게임그러니 생각난건데 1달 안쯤엔 엔비디아에서 실시간으로 애셋 렌더링하는 사례도 나왔다.

글쓰기

파운데이션 모델의 출발지부터가 글과 관련 되어있으니 관련되어있지 않을 수가 없다.

교육

손쉬운 생성, 개인화된 교육으로 확장되기 쉽다.

대화형 봇

이미 큰 시장이다. 게임사에서도 적극 활용중이다.

정보 집계

이 시장도 이미 한참 크다. 쉽게 말해 이게 초고도화되면 팔란티어.

데이터 체계화

집계 후 데이터를 체계적으로 관리하는 것 또한 확장가능하다. (저자? 역자는) AI야말로 데이터와 그래프를 설명하도록 하는 것에 적합하다고 본다.

워크플로우 자동화

오픈클로가 그 난리를 치고 클로드가 그걸 내제화하는 걸 보면 이미 말 다했다

AI 애플리케이션 기획

이걸 하려고 한다면, 생계를 위해 한다면 수익성까지 함께 고려해야 한다.

활용사례 평가

이걸 왜만들지? 돈 벌려고 하는거니까, 위험수준이 높은 수준부터 낮은 수준까지를 나열한다.

1. AI를 가진 경쟁사에 밀려 생존이 위협되는 경우 - 이럼 살려면 해야된다
2. 이익과 생산성 증대를 위한 기회를 포착하려는 경우 - 비즈니스 운영에 적정부분 도움이 된다
3. 안해도 되는데 뒤쳐지기 싫은 경우 - R&D 하는 것만 해도 가능. 여유로울 때

그럼 직접 만든다고 할 때는 회사에서 만드느냐/외주를 맡기느냐도 하나의 판단요소이다. 수익과 생산성을 높이기 위해서는 회사에서 만드느냐/솔루션을 사느냐도 판단요소가 된다.

애플리케이션에서 AI와 사람의 역할

AI의 역할에 따라 개발방식과 요구사항이 달라진다. 이를테면

1. 핵심적/보완적
   • AI없이도 돌아가면 AI는 이 앱에 보완적이다
   • AI가 앱의 코어면 정확하고 실수가 없어야 된다
2. 반응형/선제형
   • 반응형: 지연시간이 짧아야함
   • 선제형: 계산 후 전달, 적절할 때 보여줌 - 지연시간에 상대적으로 여유
3. 동적/정적
   • 동적 방식^[5]: 피드백으로 지속 업데이트 필요
   • 정적 방식^[6]: 주기적으로 업데이트 필요

애플리케이션에서 사람의 역할도 명확히 해야한다. AI주도로 할것인지, AI 의사결정 과정에 사람이 개입할 것(Human-in-the-loop)인지를 정한단 뜻이다.

지속적으로 AI 시스템 품질이 좋아지면 이 역할도 달라질 수 있다. AI가 못미더울 땐 사람이 많이 쓰다가, 점점 좋아지면(수락률 등으로 판단) 간단한 건 AI로 대체한다거나.

AI 제품 방어 가능성

누구나 만들 수 있다는건 쉽게 대체될 수 있다. 그것을 방어 가능성(defensibility)이라고 한다. 내가 쉽게 할 수 있으면 경쟁사도 쉽게 할 수 있다. 제품 방어를 위한 방어막이 있나?

AI 분야의 경쟁우위는 기술력, 데이터, 그리고 유통력(사용자에게 제품을 전달하는 능력)에 있다. 파운데이션 모델을 쓰면 기술은 비슷할거고, 유통력을 대기업 이상으로 할 수 있을까?

데이터의 우위도 마찬가지. 대기업의 데이터보다 스타트업의 데이터가 더 나으려면, 제품을 씀으로 인해 오는 사용 데이터를 모으는 것이 급선무일 것이다. 그 결과 좋으면 모델학습에 쓰고, 아니더라도 사용자 패턴이나 제품 단점에 대한 피드백을 얻을 수 있다. 이것 만으로도 귀하다.

혹은 틈새시장을 노리는 것도 포인트다. 대기업의 일부 기능이 될 수 있었을 법한 서비스가 여전히 건재한 이유가 무엇일까를 생각해보면 좋겠다.

기대치 형성

AI 앱을 만들려면, 이로 인한 성공이 뭘지, 성공은 무엇에 기준할 것인지에 대한 기준점도 잡아야 한다. AI 앱이 비즈니스에 어떤 영향을 줄지 알아야한다.

챗봇으로 친다면:

1. 자동화하려는 고객 메시지의 비율 선정
2. 처리하려는 메시지의 양
3. 챗봇을 인한 응답속도
4. 인력절감

이 포인트가 될 수도 있겠다. 그리고 위 포인트가 맞는지/아닌지도 계속 추적해서 판단준칙으로 세울 수 있는지도 검증해야한다. 이런 기준점은 [[10.2 사용자 피드백]] 을 참고.

최소성능이 어느정도인지도 명확히 정해야 한다. 고객이 쓸 정도는 어떤 성능이 필요한지의 기준점을 잡아야한다.

• 챗봇 응답품질 지표
• TTFT(첫 토큰까지 걸리는 시간), TPOT(출력 토큰 당 시간), 전체 지연시간을 포함한 지연시간 지표, 수용 가능한 지연시간
• 비용지표: 추론 요청당 비용
• 기타지표: 해석 가능성, 공정성

마일스톤 계획

목표를 잡았으면 계획도 잡아야 한다. 목표달성 방법은 시작점에 따라 다른데, 먼저 존재하는 모델의 성능을 평가해서 능력을 파악해야한다. 기존 모델이 강력하면 할게 줄어든다.

평가해보면 자원이 수익보다 클 수 있다. 그럼 과감히 접어야할 필요성을 느낄 수도 있다.

데모는 쉬울 수 있으나, 제품으로 이어지기 까진 수년이 걸릴 수 있다. 울트라챗 논문^[7]에도 그런 말이 나왔다.

유지보수

심심하면 변한다. 겪어봤으니 알지. 그럼 유지보수가 진짜 어렵다. 변하는 건 다양하게 바뀐다.

모델의 한계가 달라질 수도 있다. 이게 긍정적인가? 아닐 수도 있다. 실제 업무에서는 어려움이 될 수도 있다. 시장 상황을 매일같이 봐야한다. 이를테면 대규모 멀티태스크 언어 이해(MLLU)(Hendrycks et al., 2020)^[8] 에서도 추론 비용과 모델 성능이 얼마나 늘었나 볼 수 있다. 비용-편익 분석이 필요하단 소리다.

적응이 쉬운 변화도 있다. API 교체에 따른 작업과정, 프롬프트, 데이터 등을 새 모델에 맞게 재조정하는 것을 의미한다. 버전관리/평가 인프라가 있어야 비로소 빠르게 처리할 수 있다.

적응하기 어려운 변화도 있다. 법률제정이 있다면? 유럽은 GDPR이 꽉잡고있고, 준수하기도 힘들다. 미국 행정명령에 따라 GPU 연산을 못쓰게 된다거나 할 수도 있다.

IP(Intellectual Property)와 AI사용 규제가 계속 바뀌면? 실컷 만들어놓은 IP가 "내것"이 아니게 된다면?

이런 것들을 종합적으로 보아야 한다. 만들기로 했다면 스택을 살펴보자

AI 엔지니어링 스택

도구와 기술에 중점을 두지 않고 기본 구성요소를 보자.

AI 엔지니어링은 ML 엔지니어링에 기반한다. 둘의 태스크는 상당히 중복된다. 그럼 계층별로 분석해서 각 계층이 AI 엔지니어링, ML 엔지니어링에서 수행되는 역할을 보자.

AI의 세 계층

1. 앱 개발
   • 모델에 적절한 프롬프트와 필요 컨텍스트를 제공
   • 좋은 애플리케이션은 좋은 인터페이스를 필요로 함
2. 모델 개발
   • 모델 개발도구: 모델링, 학습, 파인튜닝, 추론 최적화 프레임워크
   • 데이터셋 엔지니어링(데이터가 모델의 코어니까)
3. 인프라
   • 모델 서빙, 데이터, 컴퓨팅 관리, 모니터링을 위한 도구

챗GPT 출시 후 위 범주에 대한 repo갯수도 폭발적으로 늘었다. 애플리케이션, AI 엔지니어링을 알아야되고, 인프라도 물론이다.

하지만 AI 앱 개발의 원칙은 동일하다.

1. 비즈니스 문제 해결을 최우선 준칙으로 둘 것. 비즈니스 지표와 ML 지표 간 상호 연계가 필요하다
2. 체계적인 실험을 갖출 것
   • ML에서는 하이퍼파라미터로 실험
   • 파운데이션 모델에서는 서로다른 모델, 프롬프트, 검색 알고리즘, 샘플링 변수(2장 참조) 등으로 실험
   • 운영환경 데이터를 바탕으로 앱 반복 개선을 위한 피드백 루프 구축

위의 것들은 ML 엔지니어가 해왔던 것들이다. AI 엔지니어링 만의 혁신은 어떤게 있는지 함께 살펴보자.

AI 엔지니어링 vs ML 엔지니어링

어떤 부분이 기존과 다른지 살펴보자. 파운데이션 모델을 사용한 개발과 기존 ML 엔지니어링과의 차이는 크게 3가지로 꼽을 수 있다

상술하였듯 AI 엔지니어링은 모델 개발보다는 모델 조정, 평가에 더 중점을 둔다.

모델 조정 기법은 모델 가중치를 업데이트 해야하는지에 따라 두 범주로 나뉠 수 있다.

1. 프롬프트 기반 기법(프롬프트 엔지니어링 등)은 모델 가중치 업데이트 없이 모델의 동작을 조정한다.
   • 지시와 컨텍스트로 세부조정한다
   • 더 많은 모델을 자유롭게 실험할 수 있다
   • 복잡한 작업, 성능에 대한 기준이 있는 앱이면 이것만으론 불충분할 수 있다.
2. 파인튜닝은 모델 가중치를 업데이트 해야한다.
   • 모델 자체를 깎아서 새 작업에 맞게 조정한다
   • 더 복잡하고 더 많은 데이터가 필요하지만 모델의 품질, 지연 시간 비용 개선이 크다

모델 개발

전통적인 ML 개발과 가까운 계층이다. 아래 세 구성요소가 있다.

• 모델링과 학습
• 데이터셋 엔지니어링
• 추론 최적화

1. 모델링과 학습
   • 모델 아키텍처 고안, 학습, 파인튜닝을 수행
   • 관련 ML 지식이 필요하다
     • (ML 알고리즘, 피드포워드, 순환, 합성곱, 트랜스포머 등의 신경망 아키텍처)
     • (경사 하강법, 손실 함수, 정규화 등의 개념을 포함한 모델의 학습방법)
   • 관련 도구 - 텐서플로우, 트랜스포머, 파이토치
   • 이를 알면 사용 가능한 도구의 폭이 넓어지고, 문제 해결에 강점이 생긴다.

^callout-learning-types

데이터셋 엔지니어링

AI 모델의 학습과 조정에 필요한 데이터를 선별하고, 생성하고, 주석을 다는 것이다.

ML 엔지니어링은 폐쇄형으로 다루었다. 모델 출력은 정의된 값 중 하나만 될 수 있었다(E.g., 스팸임/스팸아님) 파운데이션 모델은 개방형이므로 개방형 질의(데이터)에 주석을 다는 것은 훨씬 어렵다.

ML 엔지니어링은 정형 데이터를 주로 다룬다. AI 엔지니어링에서는 비정형 데이터를 주로 다룬다. AI 엔지니어링에서의 데이터 가공은 중복 제거, 토큰화, 컨텍스트 검색, 민감정보와 유해 데이터를 제거하는 품질관리에 더 촛점을 둔다. 데이터셋 엔지니어링은 8장에서 다룬다.

이렇다보니 모델이 대중적 기술인 상황이 왔고 데이터가 주요 차별점이 될 것이다는 주장이 나온다. 필요한 데이터는 상기 말한 모델 조정기법에 따라 달라진다.

추론 최적화(inference optimization)

모델을 더 빠르고 저렴하게 만드는 것이다. 빠르고 저렴한 추론으로 이득 극대화를 노리는 것은 당연한 기대다. 추론 최적화는 ML 엔지니어링 시절부터 중요핬다.

파운데이션 모델은 자기회귀적(autoregressive)이다. 토큰이 순차적으로 생성되며, 모델이 토큰 하나를 생성하는데 10ms 가 걸린다면 100개의 토큰으로 된 출력을 생성하는덴 1초가 걸린다. 더 긴출력엔? 더 많은 시간이 걸린다. 유저는 빠른 속도를 원한다. 그렇다보니 AI 애플리케이션도 100ms^[9] 까지 빨라지길 사람들이 원한다.

이 내용(양자화, 증류, 병렬화)은 7장부터 9장까지 다룬다.

평가(evaluation)

위험을 완화하고 기회를 발견하는 과정이다. 즉 모델 조정 주기에 걸쳐 평가가 이루어져야 한다. 구체적으로 평가는 모델을 선택하고, 진행상황을 벤치마크 하며, 애플리케이션의 배포 준비 여부를 판단하는 데 쓰인다. 운영 중인 시스템의 문제점을 찾아내고 개선의 기회를 발견하는 데도 필수다.

파운데이션 모델에선 특히 더 중요하다. 3장에서 보겠지만, 이 이유는 모델의 개방성과 확장된 능력에 기인한다. 폐쇄형 ML 모델은 정/오가 꽤나 뚜렷하지만 하나의 정답이 없고, 프롬프트에 대한 무수히 많은 응답이 가능하므로 정답목록은 구체화할 수 없다.

조정기술도 너무 많아서 평가도 더욱 어렵다. 하나의 기법에선 성능이 좋지 않은 시스템이 다른 기법에서는 훨씬 더 나은 성능을 보일 수 있다. 이 내용은 책을 꼭 참조하기 바란다. Gemini 첫 출시 당시 구글측은 MMLU 벤치마크(Hendrycks et al., 2020)^[10]에 기반하여 우수하다고 주장했다. 또 동시에 CoT@32^[11]라는 프롬프트 엔지니어링 기법으로 평가하기도 했다. 프롬프팅 하는 방법에 따라 다 다르다는 얘기다. (여담으로 이러니까 전문가 강의가 크게 의미없다고 하는구나)

프롬프트 엔지니어링 및 컨텍스트 구성

프롬프트 엔지니어링만 잘 해도 Gemini Ultra MMLU 성능이 83.7%에서 90.04%로 상승했다고 하니.

그리고 프롬프트 엔지니어링은 적절한 지시 뿐만 아니라 주어진 작업을 수행하는데 필요한 컨텍스트, 도구를 모델에게 제공하는 것 또한 의미한다. 롱 컨텍스트가 필요하면, 메모리 관리 시스템을 만들어 줘야할 수도 있다(이조차도 요즘 1M 컨텍스트를 기본적으로 담으니 또 달라지지않을까?). 5장에서는 프롬프트 엔지니어링을, 6장에서는 컨텍스트 구성을 다룬다.

AI 인터페이스

사용자가 AI 앱과 상호작용하는 인터페이스를 말한다. 챗지피티, 퍼플렉시티, 클로드는 독립 제품으로 나오기도 하고, Copilot은 vscode 플러그인이나 GitHub 생태게에 녹아드는 것을 선택했다. Grammarly는 브라우저 확장 프로그램을 선택했다. Midjourney는 웹 앱 혹은 디스코드 통합을 택했다.

채팅 인터페이스가 주류지만, 음성 기반/실체화된 형태(AR, VR, etc.)일 수도 있다. 이런 새로운 AI 인터페이스는 사용자 피드백을 수집하고 추출하는 방법도 다 다를 것이다. 피드백을 받게하는 건 또 쉽지만, 그걸 가지고 쓸 수 있는 데이터로 가공하는 것도 다른 문제다. 사용자 피드백 설계는 10장에서 다룬다.

그렇다보니 앱 개발에서 범주별 중요도는 아래와 같다.

AI 엔지니어링 vs 풀스택 엔지니어링

인터페이스에 대한 강조가 커지며 풀스택 개발에 더 가까워지고 있다. ML 엔지니어링은 파이썬이 주류였는데, 자바스크립트나 다른 언어에 대한 지원도 많아지고있다.

ML 엔지니어링은 데이터를 모으고 학습하는 것 부터 시작하고 제품은 마지막에 깎는다. 하지만 AI 모델을 쓰는 요즘은 제품을 먼저 만들고, 괜찮다 싶을 때(viable) 데이터와 모델에 투자하는 것도 되더라.

마치며

파운데이션 모델의 등장으로 인한 기본 입문내용을 다뤘고, 나머지는 보면서 추가적으로 딥하게 판다. AI 엔지니어링은 ML 엔지니어링에 기반한다는 사실을 기억하고, 둘의 차이와 AI 엔지니어링에서의 주안점, 트레이드오프도 잘 기억하자.

항상 하기전에 왜 해요?를 생각하자.