온디바이스 기반 모델에 대한 프롬프트 디자인 및 안전성 살펴보기 (Explore prompt design & safety for on-device foundation models) - WWDC25
생성형 AI를 매우 흥미로운 기술로 핵심 과제는 다양한 실제 상황에서도 앱 사용자에게 잘 작동하는 강력한 경험을 만드는 것.
이번 영상에서는 이런 경험을 만드는데 도움이 되는 가이드라인을 제시함.
개발자, 디자이너, 기획자 등 모두에게 도움이 되는 세션
프롬프트는 생성형 AI 모델에 입력해 응답을 이끌어 내기 위한 텍스트 내용
자연어로 작성하고, Apple Intelligence에서 지원하는 모든 언어로 입력 가능함.
Foundation Models 사용하면 프롬프트가 온디바이스 LLM으로 전송됨.
LLM은 추론 및 생성이 가능하면서 범용적이고 iOS, PadOS, macOS 및 VisionOS 등 모든 OS에 내장되어 있음.
애플 내부에서 글쓰기 모델에서 이와 동일한 원리로 모델에 프롬프트를 사용함.
온디바이스 언어 모델별로 디자인 전력을 살펴본 다음에 프롬프트 모범 사례에 대해서 알아보고자 함.
AI의 안전을 위한 디자인 과정을 살펴보고 품질과 안전을 위한 프롬프트 평가 및 테스트 전략에 대해서 알아보고자 함.
요약, 분류, Multi-turn 대화, 텍스트 구성, 텍스트 수정, 텍스트 태그 생성 등 LLM은 정말 다양한 일을 할 수 있음.
다만, 명심할 점은 LLM이 소형 기기 규모에 맞게 최적회 되고 압축되어 있다는 것.
온디바이스 LLM은 30억개의 매개변수로 구성되는데, 어떤 기준에서도 30억 개면 거대한 머신러닝 규모임
하지만, ChatGPT같은 모델은 수백억 개 100B+ 이상으로 구성되어 서버에서 구성됨.
즉, 이러한 규모의 차이 때문에 서버 기반의 LLM 만큼 동작할 수 없음.
기본적으로 이러한 차이는 같은 행위에 대해서 서버 기반의 LLM와 똑같이 작동하지 않을 수 있음.
복잡한 추론 작업에 대해서 양호한 결과가 나오지 않은 경우에는 작업 프롬프트는 더 간단한 여러 단계로 나눠서 처리해야 함.
수학 관련 작업의 경우 이러한 소규모 모델에 계산기 역할을 요청하는 것은 피하는 것이 좋은데, 수학에서는 AI가 아닌 코드를 더 신뢰할 수 있음.
온디바이스 모델은 코드에 최적화되어 있지 않기에 Cursor나 ChatGPT에 코드를 생성하는 등의 작업을 온디바이스에서 피하는 것이 좋음.
온디바이스 모델은 규모가 작기 때문에 Global Knowledge가 한정적임.
즉, 학습 이후에 발생한 최근 지식에 대해서는 잘 알지 못함.
따라서 특정한 지식 없이 특정 주제에 대해 말하는 사실을 완전히 신뢰하지 말 것.
하나의 예시로 베이글에 대한 정보를 요청했을 때 LLM은 베이글을 알고 있지만 Plain에 토핑이 들어간다고 잘못 설명하고 있음.
이건 명백히 틀린 내용으로 하나의 규칙이나 사전처럼 사용하면 안 됨
하지만 베이글을 주문하는 간단한 게임에서는 활용 가능함.
사용자의 입력을 프롬프트화 해서 간단한 대화를 생성할 수 있음.
이런 경우에는 모델이 실수를 하더라고 이상한 맛은 허위라기보다 재미있다는 느낌을 줄 수 있음
다음으로는 할루시네이션에 대해서 이해하는 것이 중요함
모델은 알지 못하는 것에 대해서 할루시네이션 현상을 보일 수 있는데 할루시네이션은 완전한 허위 답변을 작성에 대한 걸 뜻하는 기술 용어임.
즉, 사실이 중요한 경우에는 할루시네이션을 경계해야 하며, 사실 확인을 위해 모델에 의존해서는 안됨.
사실을 생성하려면 검증된 정보로 작성한 프롬프트를 모델에 제공하는 방식을 고려해야 함.
프롬프트를 새로 작성할 때마다 출력값이 사실인지 확인해야 함.
Foundation Models에서는 Guided generation을 통해 신뢰성을 향상할 수 있음
Guided generation을 통해 문자열, 숫자, 배열 등 사용자가 커스텀하게 정의한 데이터 구조 등 모델이 생성해야 하는 구조를 제약할 수 있음.
프롬프트 엔지니어링은 매우 중요함.
사용자는 시스템 모델이 생성하는 콘텐츠의 양을 모델에 지시해 제어할 수 있음.
"세 문장으로, 몇 마디로" 등의 문구로 출력을 줄일 수 있음. (In three senteces, in a few words)
"자세히"와 같은 문구를 사용하면 생성되는 출력이 길어짐 (In detail)
프롬프트에서 역할을 지정하면 모델이 생성하는 텍스트의 스타일 및 어조를 제어할 수 있음.
(예제는 셰익스피어 시대의 스타일로 글 쓰라는 의미)
즉, 모델은 프롬프트에 따라 다양한 역할을 수행할 수 있음.
애플의 Foundation Models 훈련받은 방식을 기반으로 프롬프팅에 제일 좋은 예시를 알려주고자 함.
- 프롬프트를 명확한 명령으로 구문화
- 전반적으로 모델은 상세한 특정 작업 하나를 받을 때 최고의 성능을 발휘
- 원하는 출력에 대한 예시를 제공했을 때 모델의 작업 성능이 향상됨 (일반적으로 5개 미만)
- 대문자를 사용할 경우 모델은 전체 대문자 명령을 중요하게 받아들임
- MUST, DO NOT 등을 사용해 엄격하게 표현함.
플레이그라운드를 활용해 앱에서 제일 잘 작동하는 프롬프트를 확인하기 제일 좋음.
프롬프트를 수정해 가면서 테스트하기 좋음.
프롬프트 엔지니어링의 Best Practices은 Instructions에도 그대로 적용하기 좋음
Foundation Model 프레임워크의 두 번째 프롬프트로 Instructions은 프롬프트의 두번째 종류인데 목적이 약간 다름.
LLM은 세션을 만들 때 Instructions을 인자로 포함할 수 있음.
Instructions는 모델이 어떻게 활동하고 응답해야 하는지 모든 후속 프롬프트에 알려주는 특별한 프롬프트임.
Instructions을 추가하면 모델은 다른 모든 프롬프트보다 Instructions을 우선적으로 받아들임.
즉, 모든 프롬프트에 Instructions이 적용되어서 나옴.
프롬프트는 앱 개발자만 작성하라는 법은 없고 누구든 작성할 수 있음.
Instructions과 함께 사용하면 대화형 모델 세션을 만들어 앱 사용자도 프롬프트를 작성하도록 할 수 있음.
이 시나리오에서 사용자의 입력을 모델의 프롬프트로 가져올 때 사용자가 어떤걸 입력할 지 알 수 없음.
즉, 프롬프트는 안전에 영향을 주는데 우연이든 의도적이든 사용자의 프롬프트 때문에 모델이 도움이 되지 않거나 유해한 방식으로 응답할 수 있음.
안전을 위해 Apple의 핵심 가치를 반영한 Apple Intellignece 기능에 대한 일련의 원칙이 마련되어 있음.
Foundation Model 프레임워크를 디자인할 때도 이 원칙을 따름.
생성형 AI는 오용될 수도 있고 해를 끼칠 수도 있음.
Foundation Model는 안전한 앱 경험을 만들도록 일종의 가드레일이 존재함.
앱의 사용 사례에 따라 발생할 수 있는 문제도 고려해야 함.
개인정보 보호를 고려해 모델과 프레임워크가 디자인되었음.
고정 관념과 체계적 편향(systemic bias)이 영구적으로 자리 잡지 않도록 모델을 지속적으로 개선하고 있음.
* systemic bias: 특정 결과를 뒷받침하려는 과정의 내재적 경향.
Foundation Model에는 Apple에서 훈련한 가드레일이 있어 사용자가 최악의 상황을 걱정할 필요가 없음.
가드레일은 인풋과 아웃풋 모두에 적용됨
Instuctions, promt, Tool calling 모두 모델에 대한 입력으로 간주하며, 가드레일은 유해한 입력을 차다하도록 디자인 되었음.
또한 모델의 출력도 가드레일의 보호 대상인데 덕분에 유해한 모델 출력이 차단됨.
입력 가드레일을 우회하게 작성된 프롬프트라도 마찬가지임.
Swift에서는 가드레인 오류를 catch할 수 있는데, 해당 오류가 발생하면 사용자에게 어떻게 전달할지 생각해야 함.
앱 개발자가 미리 입력해 둔 입력으로 인해 즉, 사용자가 명령한 것이 아니라면 오류를 무시하면 되며, 예상치 못한 정보로 UI를 방해할 필요가 없음.
사용자 주도 기능, 특히 사용자가 기다리고 있는 기능이라면 적절한 UI 피드백을 제공해 입력을 처리할 수 없음을 제공해야 함.
애플의 이미지 플레이 그라운드에서는 안전 오류를 유발한 프롬프트를 사용자가 취소할 수 있게끔 함.
Foundation Model은 좋은 시작점이지만 앱의 경험은 여전히 개발자의 책임임.
사용자가 신뢰할 수 있도록 기대에 맞는 적절한 콘텐츠를 만들어야 함.
앱 사용자의 신뢰를 구축하는 세가지 요소는
- 앱이 부적절한 콘텐츠를 생성하지 않도록 주의하기
- 사용자의 입력을 주의해서 처리해야하는데 Instructions과 promts를 잘 처리해야 함.
- 사용자가 응답에 따라 행동했을 때 어떻게 될지 어떤 영향을 미칠지도 생각하기
응답에 대한 안전성을 향상하려면 Instructions에 조치하는 것이 좋음.
위 이미지 예시처럼 Instructions를 활용하면 부정적이 응답에 공감은 하지만 건전한 내용으로 답하라고 모델에 알려줄 수 있음.
완벽한 예방책은 아니지만 안전에 대한 Instructions을 주의깊게 작성하면 응답 품질이 향상됨.
반드시 앱 개발자만 Instructions을 만들고 신뢰할 수 없는 콘텐츠 또는 사용자의 입력은 포함하지 않아야 함.
대신 프롬프트에 사용자의 입력을 포함할 수 있음.
일반적인 패턴은 사용자의 입력을 직접 프롬프트로 사용함.
앱 사용자에게 입력을 받는 챗봇을 생각해보면, 이러한 패턴은 유연하지만 안전에 대한 위험도 존재함.
이러한 패턴이 필요한 경우 사용자 입력을 주의해 처리하도록 모델엘 미리 Instructions을 제공해야 함.
유연성을 저해하지 않고 위험을 줄이는 좋은 방법은 개발자의 프롬프트와 사용자의 입력을 결합하는 것.
단순하게 결합하기 보다는 앱에서 내장된 프롬프트 목록을 제공해 사용자가 선택하게 되면 더 좋은데 프롬프트를 더 온전히 제어할 수 있음.
다른 패턴만큼 유연하지는 않지만 앱에 적합하면서 모델이 좋은 응답을 생성하게 하는 일련의 프롬프트를 엄선할 수 있는 방법.
하지만 Instructions을 잘 작성하고 사용자의 입력을 주의 깊게 처리해도 앱에는 안전에 대한 위험이 존재함.
사용자가 앱에서 콘텐츠를 생성해서 동작을 취할 때 영향과 결과를 예상해야 함.
베이글을 예시로 하면 사용자가 알러지가 있다는 것을 UI로 표시하거나 혹은 설정을 추가해 사용자가 앱에서 음식의 제한 사항을 설정해 모델의 레시피를 필터링하도록 할 수도 있음.
또 다른 예는 퀴즈 생성 앱을 만드는 경우인데, 논란의 여지가 있거나 이질적이라 대상자에게 부적절한 주제에 대한 질문을 생성하지 않도록 해야할 수도 있음.
별도의 Instructions을 추가하거나 거부 키워드 목록을 작성하는 것을 고려하기.
만약 ML 전문가라면 더 좋은 솔루션을 위해 classifier를 훈련할 수도 있음.
Instructions에 완화책을 제공하는 것 또한 궁극적으로 개발자의 책임임
더 많은 안전 시스템처럼 우리가 논의한 것을 적층식 접근 방식.
즉, 모든 계층에서 안전 문체를 놓쳤을 때만 발생하는 형태로 이들 계층들은 치즈 조각을 쌓아 놓은 것 같은 구조.
치즈 마다 구멍이 있긴 하지만 그 구멍들이 한 줄이어야만 무언가 떨어질 수 있음.
Foundation Model 프레임워크의 기초 계층은 내장되어 있는 가드레일임.
개발자는 Instructions을 통해 모델에 안전성을 추가하는데, 이러한 Instructions는 프롬프트보다 우선함.
Instructions에 안전 지침을 추가하거나 사용자의 프롬프트를 제어할 수 있게 앱을 디자인 함.
마지막으로 개발자 자체적으로 useCase를 분석해 완화책(mitigation)을 구현함
앱 빌드 시 생성형 AI를 사용하는 또 다른 중요한 단계는 평가와 테스트임.
이를 위해 품질과 안전을 위한 데이터 셋을 엄선할 수 있음.
앱의 모든 주요 사용 사례를 아우르는 프롬프트를 수집하고 안전 문제를 유발할 수 있는 프롬프트도 수집해야 함.
데이터 셋이 준비되었으면 이것을 기능의 처음부터 끝까지 실행할 수 있는 자동화 파이프라인에 대해서 디자인해야 함.
전용 명령 라인 도구나 이 목적의 UI 테스터 앱을 만들면 더 좋음.
소규모 데이터 셋의 경우에는 각 응답을 수동으로 직접 검사해 문제가 있는지 확인할 수도 있음.
만약 검사를 대규모 데이터 셋으로 확장하려면 다른 LLM을 사용해 자동으로 응답에 대해 점수를 매기도록 하는 방법을 사용할 수도 있음.
안전에 대한 오류가 있을 때 앱의 동작이 예상대로인지 확인하는 작업으로 앱에서 부적절한 경로를 테스트하는 것도 잊지 말기.
평가와 테스트에 투자하면 프롬프트 업데이트와 Apple의 모델 업데이트 과정에서 시간에 따른 경과 혹은 퇴화를 추적할 수 있음.
이를 통해 앱에 있는 Intelligence 기능의 품질과 자신감을 가질 수 있음.
Apple도 모델을 계속 업데이트해서 최신 모범 사례를 따르고 안전 문제를 해결할 예정.
안전 문제가 발생하면 Feedback을 통해 이러한 문제를 보고할 수 있음.
앱 기능에 안전 문제를 제공하는 UI를 만들수도 있음.
- 가드레일 에러를 핸들링하기
- 안전은 Instructions의 일부여야 함
- 사용자 입력을 프롬프트에 넣을 때 유연성과 안전 사이에서 균형을 생각해보기
- 인텔리전스 기능을 사용할 때 사용 사례별 완화책을 고려하기
- 평가와 테스트에 투자하면 인텔리전스 기능의 품질
- 리포트 기능을 활용새 안전문제 알리기
(참고)
https://www.youtube.com/watch?v=-aMFBj-kwdU&list=PLjODKV8YBFHZzCpA8JYE8-yvy69YBcfzK&index=12