루프 구조#
- 루프: 사용자 도메인과 모델 도메인 간의 변환
- 사용자 문제를 받아서 모델이 완성해야 할 문서나 대화기록 으로 바꿔준다.
- 모델이 응답을 생성하면 루프는 모델의 결과를 사용자 문제에 대한 해결책의 형태로 사용자 도메인에 반환한다.
- 루프는 한 번만 도는 경우도, 연달아 여러 차례 실행되는 경우도 있다.
사용자 문제#
- 사용자 문제 도메인에 포함되는 내용
- 문제가 전달되는 매체: LLM에서는 텍스트가 가장 자연스럽다.
- 추상화 수준: 추상화 수준이 높을수록 더 복잡한 추론이 필요하다.
- 필요한 맥락 정보: 대부분의 도메인에서는 사용자가 제공하는 정보 외에도 추가 정보를 검색해야 한다.
- 문제의 상태 의존성: 문제 도메인이 복잡할수록 과거 상호작용과 사용자 선호도를 기억해야 한다.
- 사용자 문제 도메인은 몇 가지 차원에서 다양한 수준의 복잡도를 갖는다.
사용자 문제를 모델 도메인으로 변환#
- 사용자 문제가 모델의 도메인으로 변환될 때 다음 기준을 충족해야 한다.
- 프롬프트는 학습 데이터와 높은 유사성을 가져야 한다.
- 프롬프트는 사용자 문제 해결과 관련된 모든 정보를 포함해야 한다.
- 프롬프트는 모델이 문제를 해결하는 결과를 생성하도록 유도해야 한다.
- 생성된 결과는 합리적인 종료 지점을 가져야 하며 자연스럽게 마무리되어야 한다.
LLM을 사용해 프롬프트 완성하기#
- 모델이 얼마나 커야 할지 결정해야된다.
- 모델이 클수록 생성 결과의 품질이 높지만, 비용이 높아진다.
- 레이턴시를 고려해라.
- 모델이 클수록 더 많은 계산을 필요로 하며, 계산이 많아짐녀 사용자가 할애할 수 있는 시간보다 많은 시간을 필요로 할 수 있다.
- 파인튜닝을 통해 더 나은 성능을 얻을 수 있는지 여부를 고려해라.
사용자 도메인으로 다시 변환하기#
- 함수 호출 모델이 출현한 이후로는 모델 출력을 사용자에게 유영한 정보로 변환하는 일이 상당히 쉬워졌다.
- 모델에 사용할 함수 목록을 제공한 다음 모델에게 텍스트를 생성하도록 요청한다.
- 모델에 실제로 현실 세계에 변화를 일으키는 기능을 제공함으로써 한 단계 더 나아갈 수 있다.
- 예시: 모델에 실제로 티켓을 구매하는 함수를 제공
- 사용자 도메인으로 변환하여 반환할 때, 의사소통 수단 자체를 완전히 바꿀 수도 있다.
- 예시: 모델은 텍스트 형태로 출력을 생성하지만 사용자가 전화로 자동 기술 지원 시스템과 대화하고 있다면 모델의 응답을 음성으로 변환해야 한다.
순전파 확대해보기#
- 순전파: 사용자 문제를 모델 도메인으로 변환하는 루프의 일부
기본 순전파 구축하기#
- 콘텍스트 검색: 프롬프트 정보로 사용할 콘텍스트 정보로 사용할 원시 텍스트를 생성하거나 불러오는 것
- 직접적인 콘텍스트: 사용자가 자신의 문제를 설명할 때 제공하는 정보에서 바로 나온다.
- 예시: 기술 지원 어시스턴트를 만들고 있다면, 사용자가 도움말 입력창에 직접 입력하는 텍스트
- 간접적인 콘텍스트: 근처의 관련 출처
- 예시: 기술 지원 어시스턴트를 만들고 있다면, 사용자 문제를 다루는 문서를 찾아 일부를 발췌해 사용할 수 있다.
- 스니펫화: 콘텍스트를 해당 프롬프트와 가장 관련 있는 청크로 나누는 것. 경우에 따라 다양한 형식의 콘텍스트 정보를 변환함으로써 텍스트 스니펫을 생성하는 것을 뜻한다.
- 예시:
- IT 지원애플리케이션이 문서 검색을 수행한 뒤 여러 페이지 결과를 반환했다면 가장 관련성 높은구절만 추출
- 콘텍스트 검색이 JSON API를 호출하는 방식이라면, 모델이 응답에 JSON 조각을 포함하지 않도록 응답을 자연어 형식으로 구성
- 스니펫 점수 매기기 및 우선순위 지정: 각 스니펫이 프롬프트에 얼마나 중요한지를 기준으로 우선순위 또는 점수를 부여해야 한다.
- 프롬프트 구성: 스니펫 자료들을 모두 조합해 최종 프롬프트를 구성
루프의 복잡도 살펴보기#
- 애플리케이션이 점점 복잡해질수록 복잡도는 여러 측면에서 나타나기 시작한다.
- 복잡해지는 상황1: 애플리케이션 상태가 많아진다.
- 예시: 채팅 세션 도중 사용자가 애플리케이션에 새로운 메시지를 보내면 애플리케이션은 데이터베이스에서 대화 스레드를 조회하고 이전 대와 내용을 다음 프롬프트를 위한 추가 콘텍스트로 사용하게 된다.
- 사용자와의 상호작용이 길어지게 되면 프롬프트에 맞게 대화 이력을 축약해야 할 수도 있다.
- 복잡해지는 상황2: 외부 콘텍스트가 많아진다.
- LLM은 아무리 뛰어난 모델이더라도 학습된 데이터에서만 답할 수 있다.
- 이러한 이유로 LLM 애플리케이션은 검색 증강 생성(RAG) 기법을 활용한다. RAG을 사용하면 모델이 학습 당시 접근할 수 없었던 출처로부터 콘텍스트를 가져와 포름포트를 보강할 수 있다.
- 복잡해지는 상황3: 추론 과정이 복잡해진다.
- 추론 과정이 복잡해질 때 해결하는 가장 효과적인 접근법은 모델이 문제에 대한 답을 제공하기 전에 단계별 사고과정을 보여주도록 요구하는 것이다.(생각의 사슬, CoT)
- 복잡해지는 상황4: 모델 외부 환경과의 상호작용이 복잡해진다.
- 도구 루프: 프롬프트에서 모델이 사용할 수 있는 하나 이상의 도구를 인식하도록 한다.
- 이름, 인수, 이름과 인수에 대한 설명이 포함된 함수처럼 보인다.
- 대화 도중 모델은 도구를 실행할지 선택할 수 있다.
- 도구 실행 루프는 사용자에게 정보를 반환하기 전에 애플리케이션과 모델 사이에서 여러 차례 반복될 수 있다.
LLM 애플리케이션 품질 평가#
- 새로운 LLM 기반 기능을 출시하기 전에 해당 기능을 프로토타이핑하고 모델이 어떻게 반응하는지 정량적으로 측정한 지표를 수집하는 시간을 반드시 가져야 한다.
- 그런 다음 배포되면, 애플리케이션은 모델과 사용자 행동을 모두 관찰할 수 있도록 텔레메트리 데이터를 기록해야 하며 이를 통해 애플리케이션 품질 저하를 빠르게 파악할 수 있어야 한다.
오프라인 평가#
- 운영 환경에 새 기능을 배포하기 전에 사용자 피드백을 대신할 모의 대체 평가 방식을 정의해야 된다.
- 코파일럿 코드 자동 완성의 경우, 해당 코드가 빠짐없이 구현되고 정상적으로 기능하는지 여부를 측정하면 되지만, 평가하기 어려운 기능도 있을 것이다.
- 최근 떠오르고 있는 방법 중하나는 LLM에게 평가자 역할을 맡기는 것이다.
- 마치 사람이 판단하는 것처럼, 대화 기록을 검토한 뒤 어떤 버전이 가장 나은지 결정하게 하는 방식이다.
- LLM 애플리케이션을 어떤 방식으로 평가하든, 가능한한 애플리케이션의 많은 부분을 평가에 포함시키도록 해야 한다.
온라인 평가#
- 애플리케이션이 만족스러운 UX를 제공하고 있는지에 대한 사용자 피드백을 살펴본다.
- 품질을 평가하는 가장 명확한 방법 중 하나는 사용자에게 직접 묻는 것이다.
- 품질에 대한 암묵적인 지표도 고려해야한다.
- 예시: 코파일럿은 코드 채택률을 핵심 지표로 사용
- 예시: 스케줄링 어시스턴트의 경우 성공적으로 생성된 캘린더의 일정 수를 측정하고 그 후에 사용자가 해당 일정의 세부 사항을 얼마나 자주 수정하는지도 추적하는 것이 좋다.