LLM의 마법은 테스트를 건너뛰도록 유혹할 수 있지만, 평가는 자신 있게 출시할 수 있는 열쇠입니다.
웹 기반 테마 빌더를 프로토타입으로 제작한다고 가정해 보겠습니다. 웹 애플리케이션에서 사용자가 회사 이름과 설명, 타겟층, 톤과 분위기를 입력하는 재미있는 도구입니다. 프런트엔드는 이를 서버로 전송합니다. 서버는 대규모 언어 모델 (LLM)을 사용하여 예상되는 톤과 분위기에 맞는 창의적인 모토와 브랜드에 맞는 접근 가능한 색상 팔레트를 생성합니다. 이 데이터를 작은 JSON 객체로 반환합니다.
이 애플리케이션을 ThemeBuilder라고 합니다.
기반 LLM을 선택하고 프롬프트를 반복합니다. 사내 디자이너는 색상 팔레트를 좋아하고 모토는 기억하기 쉽습니다.
이제 다음과 같은 질문이 있습니다.
- 프로덕션에 사용할 준비가 되었나요? 애플리케이션의 출력 품질이 충분히 일관적인지 알 수 없습니다. 일부 내부 테스터는 깨진 팔레트 또는 브랜드가 아닌 모토를 보고합니다. 한 가지 사례를 수정하면 두 가지 버그가 더 나타납니다.
- 모델을 변경할 수 있나요? 지연 시간을 절약하기 위해 동일한 LLM의 최신 버전으로 업그레이드하거나 비용을 절감하기 위해 관리형 서비스 에서 자체 호스팅 모델로 전환할 수 있습니다. 애플리케이션의 출력이 개선되는지 악화되는지 알 수 없으며 회귀를 테스트할 방법이 없습니다.
- 출시해도 안전한가요? 한 번 유해한 출력이 보고되었지만 재현할 수 없습니다. 우연인가요 아니면 출시를 차단해야 하나요?
LLM의 출력 품질이 너무 다양하기 때문에 팀에서 출시를 중단합니다. 테스트 없이 출시할 수 있다는 확신을 갖기 어렵습니다.
테스트 대신 추측하는 이유는 무엇인가요?
AI로 처음 빌드할 때는 몇 가지 출력을 살펴보고 괜찮다고 판단한 후 계속 진행하는 것이 좋습니다. 측정 및 데이터 대신 직관에 의존하는 이유는 무엇인가요?
LLM은 결정론적이지 않고 확률론적이기 때문에 이 작업을 수행할 가능성이 높습니다. 즉, 동일한 회사 이름, 설명, 잠재고객, 톤을 제공하더라도 ThemeBuilder는 다른 모토와 색상 팔레트를 출력할 수 있습니다.
재미있는 모토나 브랜드 색상 팔레트에 대한 정답은 하나로 규정되지 않습니다.
LLM의 창의성은 훌륭합니다. 하지만 비결정론은 엔지니어링의 개념과 상반되는 느낌입니다. 따라서 LLM 기반 애플리케이션은 테스트할 수 없다고 결론 내릴 수 있습니다.
평가가 도와줍니다.
LLM 세계에서는 개발 권장사항이 계속 유효합니다. LLM 기반 애플리케이션을 테스트할 수 있고 테스트해야 합니다. 다른 기법이 필요할 뿐입니다. 이러한 기법을 평가 또는 줄여서 평가라고 합니다. 평가에는 새로운 워크플로가 포함되지만 기존 테스트 전문 지식은 훌륭한 평가를 빌드하는 데 직접 적용됩니다.
평가는 AI 기능에 대한 테스트입니다. 이러한 테스트는 주요 의견 교환 루프를 만드는 데 도움이 됩니다. 강력한 평가 파이프라인을 빌드하면 LLM 기반 기능이 사용자에게 잘 작동합니다. 그러면 팀에서 자신 있게 기능을 출시할 수 있습니다.
LLM으로 빌드하는 경우 강력한 평가를 구현하는 방법을 배우는 것이 시간을 가장 잘 활용하는 방법 중 하나입니다.
이제 평가에 대해 알아보세요.