AI Engineering - Chip Huyen

ch01. intro

• tokenization: LLM 은 입력 텍스트를 기본 단위인 token 으로 쪼개 처리한다.
  • 문자, 단어, 또는 단어의 일부로 model 마다 토큰화하는 방식이 다르다. (예: gpt-4o 와 gpt-5 가 다름)
  • 평균적으로 100 token 은 75 단어이다.
  • vocabulary: model 이 다룰수 있는 모든 token 의 집합
• language model: masked LM 과 autoregressive LM 이 있다.
  • autoregressive LM 은 token 을 하나씩 순차적으로 생성한다. (최근 LLM 들은 대부분 이 타입)
• LM 의 학습은 self-supervised learning 방식으로 한다.
• LLM 이란 파라미터가 대략 1000억개 넘는 모델이다.
• foundation model 이란 범용 모델로, AI 애플리케이션의 요구사항에 맞게 발전시킬 수 있다.
• 모델 조정: 모델이 더 좋은 결과를 내놓도록 유도하는 기법으로, prompt engineering, RAG, fine-tuning 을 통해 할 수 있다.

token 에 대해 더 이해하기 (참고)

• LLM 비용은 input token, output token 에 의존한다.
• input 이 길면 초기 생성이 오래 걸리고, output 이 길면 최종 생성에 오래 걸린다.
  • streaming 방식을 통해 모든 output 이 생성되기까지 기다리지 않고 결과를 순차적으로 받을 수 있다.
• context window 크기는 이러한 input, output token 에 대한 제한이다. (autoregressive 방식이라서 input/output 을 합친것까지 context 로 봐야함.)
• (참고): https://ai.google.dev/gemini-api/docs/long-context?hl=ko

ch02. 파운데이션 모델 이해하기

• 범용 모델 (Gemini, GPT, 등) 은 다양한 도메인에서 뛰어난 성능을 보여준다.
• 이는 학습 데이터에 다양한 도메인의 데이터가 포함되었기 때문이다.

---

ch03. 평가 방법론

• foundation model 은 평가가 어렵다.

1. AI model 이 너무 정교한 작업을 한다.
2. 개방형 응답을 하므로, 전통적인 ML 평가가 불가능하다.
3. blackbox - 어떤 데이터로 학습했는지, 어디에 약한지 알 수 없고 input/output 으로 추측해야 한다.

• 많은 AI 애플리케이션은 여전히 사람 평가자가 필요하며, 이를 자동화하는 것은 모두의 목표다.

폐쇄형 평가

• 전통적인 ML 평가로, 예: classification, regression

개방형 평가

• 임의의 텍스트를 생성한다.

1. 기능적 정확성 - 원하는 기능을 수행하는가? 자동화가 항상 가능하진 않다.

• 예: 생성한 코드가 unit test 를 통과하는가?
• 예: 게임 플레이를 잘 하는가?

2. 참조 데이터 유사도 측정

• 예: A -> B 로 번역 시, 모델이 A -> C 를 응답한 경우 B <-> C 의 유사도를 측정하여 스코어를 먹인다.

• 의미적 유사도: embedding 을 통해 의미적으로 얼마나 비슷한지 계산한다.

  • 예: let's eat baby 와 let's eat, baby 는 의미적으로 거리가 멀다.

• embedding 은 텍스트 뿐 아니라, 이미지, PDF, 기업 내부 제품 등 모든 데이터의 유사도를 계산할 수 있다.

• AI 평가자: 개방형 응답의 평가는 사람에 의존한다.

  • startup demo 는 대부분 AI 평가자를 쓰고, 운영 단계에서는 사람 평가를 주로 쓴다.
  • AI 평가자의 편향: model 은 다른 model 생성 응답보다, 자신의 생성을 더 선호한다.
  • 비교 평가: 여러 model 을 테스트 해 본다.

---

ch05. Prompt Engineering

• 모델의 강건성 (robust) 이 높으면, 프롬프트가 부정확해도 좋은 결과를 반환한다.
  • 예를 들어, 더 최신 모델은 five 와 5 를 동일한 개념으로 인식할 수 있다.
• 프롬프트 모범 사례
  • 모호함 없이 설명하기, 페르소나 부여하기, 예시 제공하기, 출력 형식 지정하기
  • 복잡한 작업을 단순한 하위 작업으로 나누기 (더 많은 프롬프트로 분리)
  • CoT, self-critique
• 프롬프트 버전 관리가 중요하다.

ch06. RAG & Agent

• AI 모델의 성능 향상을 위해서는

1. 모델에게 좋은 지시를 내려야 한다. (Prompt Engineering)
2. 모델에게 적절한 컨텍스트를 제공해야 한다.

• 컨텍스트 구성을 위해 RAG 와 agent 패턴을 활용할 수 있다.

RAG

• Foundation model 의 context 구성은 ML model 의 feature engineering 과 같은 역할을 한다.

RAG architecture

• 검색기와 생성 model 로 구성된다.
• RAG 시스템의 성공 여부는 검색기 품질에 달려 있다.
• 검색기는 indexing 과 query 로 이루어져 있다.
  • indexing 은 나중에 빠르게 검색할 수 있도록 data 를 처리하는 작업이다.
  • query 는 데이터를 검색하기 위해 시스템에 요청한다.
• document 가 클 경우 chunk 로 분리한다.
• query 와 관련성 높은 chunk 를 검색하고, 찾아낸 chunk 를 prompt 와 합친다. (post-processing 이 필요하다.)

model context 가 길어져도 RAG 는 필요하다.

• 모든 걸 context 에 포함할 경우, latency 증가와 정확도 감소가 발생한다.
• claude 는 20만 토큰 미만일 경우 RAG 를 쓰지 말라고 조언했다.

검색 (retrieval)

• 먼저 키워드 기반 검색을 시도해 보고, 필요하다면 임베딩 기반 검색을 시도해라.
• lexical: bm25, elasticsearch inverted index
  • 예: 검색 키워드가 chunk 에 몇 번 등장하는지?
• semantic: 실제로 의미 기반으로 가까운지?
• lexical, semantic search 를 같이 하는 경우 hybrid search 라고 할 수 있다.
• lexical search 와 같은 가벼운 검색을 먼저, semantic search 와 같은 무거운 검색을 그 결과를 대상으로 추가로 하는 경우 reranking 으로 볼 수 있다.

ch07. fine-tuning

언제 fine-tuning 이 필요하고, 언제 RAG 가 필요한가?

• 모델의 행동 방식 (예: 특정 형식의 기술 명세서 출력, HTML 코드 작성 등) 을 조정해야 한다면 fine tuning 을 시도하라.
• 모델의 사실 정확도를 개선하려면 RAG 를 시도하라.
  • RAG 가 fine-tuning 에 비해 더 쉽고 (fine-tuning 은 학습 데이터 수집, 모델 운영이 어려움) 성능 향상이 더 수월하다.
  • fine-tuning 과 RAG 를 함께 쓸 수 있다.

모델 조정의 과정

1. 프롬프트만으로 원하는 작업을 수행하도록 한다. 프롬프트 엔지니어링 모범 사례, 버전 관리를 하자.
2. 프롬프트에 더 많은 예시를 추가한다. (1~50개)
3. 정보 부족으로 오류를 보인다면 데이터 소스에 연결한다. RAG 는 키워드 기반을 먼저 시도하라.
4. a. 모델이 정보 오류를 계속 보인다면 임베딩 기반 검색을 시도하자.
   b. 모델이 관련 없는 내용을 생성하거나 형식이 잘못되거나 안전하지 않은 응답을 생성한다면 fine-tuning 을 고려한다.
5. RAG 와 fine-tuning 을 함께 활용한다.