사람과 마찬가지로 LLM도 단일 문자를 읽지 않는다. 모델에 텍스트를 전송하면 처음에는 텍스트를 토큰(token)이라고 부르는 여러 문자로 구성된 단위(chunk)로 나뉜다. 일반적으로 서너 자 길이지만 일반적인 단어나 문자 시퀀스에 대한 더 긴 토큰도 있다. 모델에서 사용되는 토큰 집합을 어휘(vocabulary)라고 한다. / 텍스트를 읽을 때 모델은 먼저 토크나이저(tokenizer)를 통해 텍스트를 토큰 시퀀스로 변환한 다음 LLM에 전달된다. 그러면 LLM은 일련의 토큰(내부에서는 숫자로 표현된다)을 생성하고, 이는 다시 텍스트로 변환된 다음 사용자에게 반환된다.
--- p.27

현대 LLM에서 이 Q&A 메커니즘은 마스킹(masking)이라고 하는 하나의 제약을 더 따른다. 모든 미니브레인이 질문에 답할 수 있는 것은 아니다. 질문을 한 미니브레인의 왼쪽에 있는 미니브레인만 그 질문에 답할 수 있다. 그리고 미니브레인은 자신의 답변이 사용됐는지 결코 알 수 없으므로 오른쪽에 있는 미니브레인은 왼쪽에 있는 미니브레인에 결코 영향을 미칠 수 없다.
--- p.45

퓨샷 프롬프트는 콘텍스트가 커질수록 확장성이 떨어지고, 결과가 예시에 편향되며, 잘못된 패턴(spurious pattern)을 유도할 수 있다. 이렇게 여러 문제가 있음에도 불구하고, 퓨샷 프롬프트를 사용할 가치가 있을까? 경우에 따라 다르다. 퓨샷 프롬프트는 모델에게 사용자 질문의 다양한 측면을 명확하게 설명해주는 데 가장 쉬운 방법이며, 이러한 위험성은 신중한 평가 과정을 거침으로 완화시킬 수 있다(10장). 따라서 사용자 문제 도메인이 모델에게 불명확한 특정 측면을 포함하고 있고, 프롬프트 공간이 충분히 크고, 편향을 피하기 위해 주의를 기울였다면 퓨샷 프롬프트는 유용한 프롬프트 엔지니어링 도구가 될 수 있다.
--- p.110

완성형 모델을 사용하는 경우 인셉션(inception)이라는 기법을 사용할 수 있다. 이 기법은 응답의 시작 부분을 사용자가 직접 작성한다. (...) 응답의 서두를 사용자가 먼저 작성하면, 모델은 자신이 그 답을 시작한 것으로 생각하고 그에 맞춰 나머지 결과도 생성한다. 이 방식은 모델의 지시 준수도를 개선시키고 답변을 파싱하기 쉽게 만들 뿐 아니라 답변이 일반적인 진술로 시작할지 아니면 바로 요점을 짚을지에 대한 불확실성을 피하는 데 도움이 된다.
--- p.140

작업이 명확하게 잘 정의됐다면 각 작업에 대한 예제 데이터를 수집해 작업을 개선할 수 있다. 작업 구현 결과가 운영 환경에 반영되기 전에 오프라인에서 프롬프트를 실행해보고 그 결과가 기대한 행동과 일치하는지 점검하는 하네스 테스트(harness test)를 만들어야 한다. 이렇게 해두면 프롬프트를 변경할 때 해당 작업 품질을 저하시키지 않고도 안전하게 배포하기 쉬워진다. 입출력 예시 데이터는 최근 등장한 최적화 기법인 DSPy(https://arxiv.org/abs/2310.03714)와 TextGrad(https://arxiv.org/abs/2406.07496)에서도 유용하게 쓰인다. 이 프레임워크는 I/O 예제를 활용해 프롬프트를 최적화해 제공된 지표에 따라 측정된 품질을 자동으로 향상시킬 수 있다.
--- p.241

만약 제안을 직접적으로 평가할 수 없다면 대부분의 애플리케이션은 사용자가 해당 제안을 수락할지 또는 최소한 수락하려는 단계를 취했는지 여부를 점검할 수 있다. 예를 들어, 사용자가 실제로 시카고 여행을 예약했는지를 확인할 수 있다. 제안 내용에 링크가 포함되어 있다면 사용자가 해당 링크를 얼마나 자주 클릭했는지를 나타내는 클릭률(click-through rate)처럼 직접적일 수 있다. 이 지표는 제안 내용이 괜찮아 보였는지만 확인하지 실제로 유용했는지를 확인할 수 없다. 그렇지만 이 지표는 매우 중요한 출발점이 되는 경우가 많다. / 이는 코파일럿에서 발견한 사실(https://oreil.ly/qwR21)이기도 하다. 우리는 이 수용 지표가 사용자들이 느낀 생산성 향상과 함께 매우 강한 상관관계가 있다는 것을 발견했다.