[목 차]
옮긴이 머리말 ix
베타리더 후기 x
시작하며 xii
감사의 글 xv
표지에 대하여 xvi
PART I 기본 원리
CHAPTER 1 프롬프트 엔지니어링 소개 3
1.1 LLM은 마법이다 4
1.2 언어 모델: 어쩌다 우리가 여기까지 왔지? 7
1.3 프롬프트 엔지니어링 14
1.4 요약 16
CHAPTER 2 LLM의 이해 18
2.1 LLM은 무엇인가? 19
2.2 LLM이 세상을 보는 방법 26
2.3 한 번에 토큰 한 개 33
2.4 온도와 확률 37
2.5 트랜스포머 아키텍처 41
2.6 요약 47
CHAPTER 3 대화형으로 넘어가기 48
3.1 인간 피드백을 통한 강화학습 50
3.2 지시형에서 대화형으로 56
3.3 지금도 변하고 있는 API 61
3.4 극본 작성으로서의 프롬프트 엔지니어링 67
3.5 요약 69
CHAPTER 4 LLM 애플리케이션 설계하기 71
4.1 루프 구조 71
4.2 순전파 확대해보기 82
4.3 LLM 애플리케이션 품질 평가 89
4.4 요약 91
PART II 핵심 기술
CHAPTER 5 프롬프트 내용 95
5.1 콘텐츠 출처 97
5.2 정적 콘텐츠 98
5.3 동적 콘텐츠 110
5.4 요약 134
CHAPTER 6 프롬프트 구성하기 135
6.1 이상적인 프롬프트 구조 135
6.2 어떤 종류의 문서인가? 139
6.3 스니펫 형식 지정하기 150
6.4 탄력적 스니펫 153
6.5 프롬프트 요소 간 관계 155
6.6 최종 프롬프트 구성 157
6.7 요약 161
CHAPTER 7 모델 제어 162
7.1 모델 제어 162
7.2 텍스트를 넘어서: 로그 확률 168
7.3 모델 선택 175
7.4 요약 182
PART III 전문가 역량
CHAPTER 8 대화형 에이전시 187
8.1 도구 활용 188
8.2 추론 201
8.3 작업 기반 상호작용을 위한 콘텍스트 208
8.4 대화형 에이전트 구축 213
8.5 요약 219
CHAPTER 9 LLM 워크플로 221
9.1 대화형 에이전트로 충분할까? 223
9.2 기본 LLM 워크플로 226
9.3 고급 LLM 워크플로 242
9.4 요약 246
CHAPTER 10 LLM 애플리케이션 평가 247
10.1 LLM 애플리케이션 평가 248
10.2 오프라인 평가 249
10.3 온라인 평가 265
10.4 요약 269
CHAPTER 11 미래를 전망하며 270
11.1 다중 모달 처리 271
11.2 요약 277
찾아보기 279
[본 문]
사람과 마찬가지로 LLM도 단일 문자를 읽지 않는다. 모델에 텍스트를 전송하면 처음에는 텍스트를 토큰(token)이라고 부르는 여러 문자로 구성된 단위(chunk)로 나뉜다. 일반적으로 서너 자 길이지만 일반적인 단어나 문자 시퀀스에 대한 더 긴 토큰도 있다. 모델에서 사용되는 토큰 집합을 어휘(vocabulary)라고 한다. / 텍스트를 읽을 때 모델은 먼저 토크나이저(tokenizer)를 통해 텍스트를 토큰 시퀀스로 변환한 다음 LLM에 전달된다. 그러면 LLM은 일련의 토큰(내부에서는 숫자로 표현된다)을 생성하고, 이는 다시 텍스트로 변환된 다음 사용자에게 반환된다. (27쪽)
현대 LLM에서 이 Q&A 메커니즘은 마스킹(masking)이라고 하는 하나의 제약을 더 따른다. 모든 미니브레인이 질문에 답할 수 있는 것은 아니다. 질문을 한 미니브레인의 왼쪽에 있는 미니브레인만 그 질문에 답할 수 있다. 그리고 미니브레인은 자신의 답변이 사용됐는지 결코 알 수 없으므로 오른쪽에 있는 미니브레인은 왼쪽에 있는 미니브레인에 결코 영향을 미칠 수 없다. (45쪽)
퓨샷 프롬프트는 콘텍스트가 커질수록 확장성이 떨어지고, 결과가 예시에 편향되며, 잘못된 패턴(spurious pattern)을 유도할 수 있다. 이렇게 여러 문제가 있음에도 불구하고, 퓨샷 프롬프트를 사용할 가치가 있을까? 경우에 따라 다르다. 퓨샷 프롬프트는 모델에게 사용자 질문의 다양한 측면을 명확하게 설명해주는 데 가장 쉬운 방법이며, 이러한 위험성은 신중한 평가 과정을 거침으로 완화시킬 수 있다(10장). 따라서 사용자 문제 도메인이 모델에게 불명확한 특정 측면을 포함하고 있고, 프롬프트 공간이 충분히 크고, 편향을 피하기 위해 주의를 기울였다면 퓨샷 프롬프트는 유용한 프롬프트 엔지니어링 도구가 될 수 있다. (110쪽)
완성형 모델을 사용하는 경우 인셉션(inception)이라는 기법을 사용할 수 있다. 이 기법은 응답의 시작 부분을 사용자가 직접 작성한다. (...) 응답의 서두를 사용자가 먼저 작성하면, 모델은 자신이 그 답을 시작한 것으로 생각하고 그에 맞춰 나머지 결과도 생성한다. 이 방식은 모델의 지시 준수도를 개선시키고 답변을 파싱하기 쉽게 만들 뿐 아니라 답변이 일반적인 진술로 시작할지 아니면 바로 요점을 짚을지에 대한 불확실성을 피하는 데 도움이 된다. (140쪽)
작업이 명확하게 잘 정의됐다면 각 작업에 대한 예제 데이터를 수집해 작업을 개선할 수 있다. 작업 구현 결과가 운영 환경에 반영되기 전에 오프라인에서 프롬프트를 실행해보고 그 결과가 기대한 행동과 일치하는지 점검하는 하네스 테스트(harness test)를 만들어야 한다. 이렇게 해두면 프롬프트를 변경할 때 해당 작업 품질을 저하시키지 않고도 안전하게 배포하기 쉬워진다. 입출력 예시 데이터는 최근 등장한 최적화 기법인 DSPy(https://arxiv.org/abs/2310.03714)와 TextGrad(https://arxiv.org/abs/2406.07496)에서도 유용하게 쓰인다. 이 프레임워크는 I/O 예제를 활용해 프롬프트를 최적화해 제공된 지표에 따라 측정된 품질을 자동으로 향상시킬 수 있다. (241쪽)
만약 제안을 직접적으로 평가할 수 없다면 대부분의 애플리케이션은 사용자가 해당 제안을 수락할지 또는 최소한 수락하려는 단계를 취했는지 여부를 점검할 수 있다. 예를 들어, 사용자가 실제로 시카고 여행을 예약했는지를 확인할 수 있다. 제안 내용에 링크가 포함되어 있다면 사용자가 해당 링크를 얼마나 자주 클릭했는지를 나타내는 클릭률(click-through rate)처럼 직접적일 수 있다. 이 지표는 제안 내용이 괜찮아 보였는지만 확인하지 실제로 유용했는지를 확인할 수 없다. 그렇지만 이 지표는 매우 중요한 출발점이 되는 경우가 많다. / 이는 코파일럿에서 발견한 사실(https://oreil.ly/qwR21)이기도 하다. 우리는 이 수용 지표가 사용자들이 느낀 생산성 향상과 함께 매우 강한 상관관계가 있다는 것을 발견했다. (268쪽)
깃허브 코파일럿을 만든 이들이 말하는 LLM 설계의 기준
이 책은 프롬프트를 '예쁘게' 다듬는 요령을 모은 안내서가 아니다. 한두 줄의 문장으로 모델을 요령껏 다루는 방법을 기대한다면 이 책은 전혀 다른 이야기를 한다. 저자들은 LLM을 단순히 '어떻게' 쓸 것인가보다 어떤 관점으로 이해하고 어떤 구조 안에서 다뤄야 하는지를 먼저 묻는다. 콘텍스트를 수집하고 정리하는 법부터 프롬프트를 쌓아 올리는 구조, 그리고 가드레일과 평가를 통해 AI의 출력을 통제하는 법까지 실무에서 마주하는 핵심 문제들을 정면으로 다룬다. 이 논의는 자연스럽게 에이전트와 워크플로 설계라는 더 큰 시스템의 영역으로 확장된다.
그 단단한 논리의 출발점에는 깃허브 코파일럿 개발에 참여하고 실제 제품 환경에서 운영한 저자들의 독보적인 경험이 있다. 그래서 이 책은 단순한 기법 나열에 그치지 않는다. 대신 '왜 이런 설계가 필요한가', '이 방식은 언제 깨지는가'라는 날카로운 현장의 질문들을 중심으로 이야기를 전개한다. LLM을 '텍스트 완성 엔진'으로 재정의하는 냉철한 시선에서 시작해 모델이 바뀌어도 결국 남는 것은 ‘마법 같은 문장’이 아니라 '설계'라는 점을 일관되게 보여준다.
코파일럿을 직접 만든 경험에서 우러나온 이 책은 프롬프트를 단순한 입력값이 아닌 설계의 언어로 다룬다. LLM을 일회성 실험이 아니라 안정적인 시스템으로 구축하고 싶은 이들에게 이 책은 흔들리지 않는 분명한 기준점이 되어줄 것이다.
주요 내용
●LLM의 구조와 작동 원리 이해하기
●애플리케이션을 위한 프롬프트 전략 설계하기
●맥락 요소를 수집 및 분류, 제시해 효율적 프롬프트 만들기
●퓨샷, CoT, RAG 등 핵심 기법 익히기
●대화형 워크플로를 설계하고 실무에 적용하기
●성과를 평가하고 활용 전략 검증하기