안전 및 사실성 지침

안전 및 사실성 지침 (Safety and factuality guidance)

생성형 인공지능 모델은 강력한 도구이지만 한계가 없는 것은 아니에요. 이들의 다재다능함과 적용 가능성은 때로 부정확하거나 편향되거나 공격적인 출력 같은 예상치 못한 결과를 만들 수 있어요. 그러한 출력으로 인한 피해 위험을 줄이려면 후처리(post-processing)와 엄격한 수동 평가가 필수적이에요.

Gemini API가 제공하는 모델은 다양한 생성형 AI 및 자연어 처리(NLP) 애플리케이션에 사용할 수 있어요. 이러한 기능은 Gemini API 또는 Google AI Studio 웹 앱을 통해서만 사용할 수 있어요. Gemini API 사용에는 생성형 AI 금지 사용 정책과 Gemini API 서비스 약관이 적용돼요.

대규모 언어 모델(LLM)이 이토록 유용한 이유 중 하나는 다양한 언어 작업을 처리할 수 있는 창의적인 도구이기 때문이에요. 안타깝게도 이는 LLM이 공격적이거나 무감각하거나 사실적으로 틀린 텍스트를 포함한 예상치 못한 출력을 생성할 수 있다는 뜻이기도 해요. 게다가 이 모델들의 놀라운 다재다능함이 바로 어떤 종류의 바람직하지 않은 출력을 만들어낼지 예측하기 어렵게 만드는 이유예요. Gemini API는 Google의 AI 원칙을 염두에 두고 설계되었지만, 이 모델을 책임 있게 적용할 책임은 개발자에게 있어요. 개발자가 안전하고 책임 있는 애플리케이션을 만들 수 있도록 Gemini API에는 내장 콘텐츠 필터링과 4가지 피해 차원에 걸친 조정 가능한 안전 설정이 있어요. 자세한 내용은 안전 설정 가이드를 참고하세요. 또한 사실성을 높이기 위해 Google 검색 기반 그라운딩(Grounding)을 제공하지만, 정보 탐색이 아닌 창의적인 사용 사례를 가진 개발자에게는 비활성화될 수 있어요.

이 문서는 LLM을 사용할 때 발생할 수 있는 몇 가지 안전 위험을 소개하고, 새로 등장하는 안전 설계 및 개발 권장 사항을 제안하기 위한 것이에요. (법률과 규정이 추가 제한을 부과할 수도 있지만, 그러한 고려 사항은 이 가이드의 범위를 벗어나요.)

LLM으로 애플리케이션을 구축할 때 다음 단계를 권장해요.

애플리케이션의 안전 위험 이해하기
안전 위험을 완화하기 위한 조정 고려하기
사용 사례에 적합한 안전 테스트 수행하기
사용자 피드백 수집 및 사용량 모니터링하기

조정과 테스트 단계는 애플리케이션에 적합한 성능에 도달할 때까지 반복적으로 수행해야 해요.

출처: 원문

본문

애플리케이션의 안전 위험 이해하기

여기서 안전은 LLM이 독성 언어나 고정관념을 조장하는 콘텐츠를 생성하는 등 사용자에게 피해를 주지 않도록 하는 능력으로 정의돼요. Gemini API를 통해 제공되는 모델은 Google의 AI 원칙을 염두에 두고 설계되었으며, 사용에는 생성형 AI 금지 사용 정책이 적용돼요. API는 독성 언어와 혐오 발언 같은 일반적인 언어 모델 문제를 해결하고 포용성을 추구하며 고정관념을 피하기 위한 내장 안전 필터를 제공해요. 하지만 각 애플리케이션은 사용자에게 서로 다른 위험을 제기할 수 있어요. 따라서 애플리케이션 소유자로서 여러분은 사용자를 알고, 애플리케이션이 일으킬 수 있는 잠재적 피해를 파악하며, 애플리케이션이 LLM을 안전하고 책임 있게 사용하도록 보장할 책임이 있어요.

이 평가의 일부로 피해가 발생할 가능성과 그 심각성, 완화 단계를 고려해야 해요. 예를 들어 사실적인 사건을 바탕으로 에세이를 생성하는 앱은 오락을 위해 허구적 이야기를 생성하는 앱보다 오정보(misinformation)를 피하는 데 더 주의해야 해요. 잠재적 안전 위험 탐색을 시작하는 좋은 방법은 최종 사용자와 애플리케이션 결과의 영향을 받을 수 있는 다른 사람들을 조사하는 거예요. 여기에는 앱 도메인의 최신 연구 조사, 유사한 앱을 사람들이 어떻게 사용하는지 관찰, 사용자 연구·설문 조사 실시, 또는 잠재적 사용자와의 비공식 인터뷰 등 다양한 형태가 있어요.

고급 팁 (Advanced tips)

대상 인구 내의 다양한 예비 사용자들과 애플리케이션 및 의도된 목적에 대해 대화해 잠재적 위험에 대한 더 넓은 시각을 얻고 필요에 따라 다양성 기준을 조정하세요.
미국 정부의 국립표준기술연구소(NIST)가 발표한 AI 위험 관리 프레임워크는 AI 위험 관리에 대한 더 상세한 지침과 추가 학습 자료를 제공해요.
DeepMind의 언어 모델로 인한 윤리적 및 사회적 피해 위험에 관한 논문은 언어 모델 애플리케이션이 피해를 일으킬 수 있는 방식을 자세히 설명해요.

안전 및 사실성 위험을 완화하기 위한 조정 고려하기

이제 위험을 이해했으니 이를 어떻게 완화할지 결정할 수 있어요. 어떤 위험을 우선순위로 삼을지, 위험을 예방하기 위해 얼마나 많은 노력을 해야 할지 결정하는 것은 소프트웨어 프로젝트의 버그를 분류하는 것과 유사한 중요한 결정이에요. 우선순위를 정하고 나면 가장 적절한 완화 유형을 고려하기 시작할 수 있어요. 종종 간단한 변경만으로도 차이를 만들고 위험을 줄일 수 있어요.

예를 들어 애플리케이션을 설계할 때 다음을 고려해 보세요.

모델 출력 조정: 애플리케이션 컨텍스트에서 허용 가능한 것을 더 잘 반영하도록 모델 출력을 조정해요. 조정은 모델 출력을 더 예측 가능하고 일관성 있게 만들어 특정 위험을 완화하는 데 도움이 될 수 있어요.
더 안전한 출력을 촉진하는 입력 방법 제공: LLM에 주는 정확한 입력은 출력 품질에 차이를 만들 수 있어요. 입력 프롬프트를 실험해 사용 사례에서 가장 안전하게 작동하는 것을 찾는 것은 충분히 가치 있는 노력이에요. 그렇게 하면 그것을 촉진하는 UX를 제공할 수 있으니까요. 예를 들어 사용자를 입력 프롬프트의 드롭다운 목록에서만 선택하도록 제한하거나, 애플리케이션 컨텍스트에서 안전하게 작동한다고 확인된 설명적 문구가 있는 팝업 제안을 제공할 수 있어요.
안전하지 않은 입력 차단 및 사용자에게 보여주기 전에 출력 필터링: 간단한 상황에서는 블록리스트를 사용해 프롬프트나 응답의 안전하지 않은 단어나 문구를 식별하고 차단하거나, 인간 검토자가 그러한 콘텐츠를 수동으로 수정하거나 차단하도록 요구할 수 있어요.

참고: 정적 목록에 기반한 자동 차단은 블록리스트의 어휘를 흔히 사용하는 특정 그룹을 표적으로 삼는 것 같은 의도치 않은 결과를 초래할 수 있어요.

훈련된 분류기 사용해 각 프롬프트를 잠재적 피해 또는 적대적 신호로 라벨링: 감지된 피해 유형에 따라 요청 처리에 서로 다른 전략을 적용할 수 있어요. 예를 들어 입력이 명백히 적대적이거나 모욕적인 성격이라면 차단하고 대신 사전 작성된 응답을 출력할 수 있어요.

고급 팁: 신호가 출력을 유해한 것으로 판단하면 애플리케이션은 다음 옵션을 사용할 수 있어요.

오류 메시지 또는 사전 작성된 출력을 제공해요.
동일한 프롬프트가 때로 다른 출력을 유발하므로, 대체 안전 출력이 생성될 수 있는지 프롬프트를 다시 시도해요.
의도적 오용에 대한 안전장치 마련: 각 사용자에게 고유 ID를 할당하고 특정 기간에 제출할 수 있는 사용자 쿼리 볼륨에 상한을 두는 것과 같은 방식이에요. 또 다른 안전장치는 가능한 프롬프트 주입(prompt injection)으로부터 보호하려는 거예요. 프롬프트 주입은 SQL 주입과 매우 유사하게, 악의적인 사용자가 입력 프롬프트를 설계해 모델의 출력을 조작하는 방식이에요. 예를 들어 이전 예시를 무시하도록 모델에 지시하는 입력 프롬프트를 보내는 방식이죠. 의도적 오용에 대한 자세한 내용은 생성형 AI 금지 사용 정책을 참고하세요.
본질적으로 위험이 더 낮은 기능으로 조정: 범위가 더 좁은 작업(예: 텍스트 구절에서 키워드 추출)이나 더 큰 인간 감독이 있는 작업(예: 인간이 검토할 짧은 형식의 콘텐츠 생성)은 종종 위험이 더 낮아요. 예를 들어 이메일 답변을 처음부터 작성하는 애플리케이션을 만드는 대신, 개요를 확장하거나 대체 문구를 제안하는 것으로 제한할 수도 있어요.
유해 콘텐츠 안전 설정 조정: 유해할 수 있는 응답을 볼 가능성을 낮추는 방식으로 조정해요. Gemini API는 프로토타이핑 단계에서 조정 가능한 안전 설정을 제공하여 애플리케이션이 더 엄격하거나 덜 엄격한 안전 구성을 요구하는지 결정할 수 있게 해줘요. 다섯 가지 필터 범주에 걸쳐 설정을 조정해 특정 유형의 콘텐츠를 제한하거나 허용할 수 있어요. Gemini API에서 사용할 수 있는 조정 가능한 안전 설정에 대해 알아보려면 안전 설정 가이드를 참고하세요.
Google 검색 기반 그라운딩 활성화로 잠재적 사실 오류나 환각 감소: 많은 AI 모델은 실험적이며 사실적으로 부정확한 정보를 제시하거나 환각을 일으키거나 다른 문제가 있는 출력을 생성할 수 있다는 점을 기억하세요. Google 검색 기반 그라운딩 기능은 Gemini 모델을 실시간 웹 콘텐츠에 연결하며 모든 지원 언어에서 작동해요. 이를 통해 Gemini는 모델의 지식 기준 시점을 넘어 더 정확한 답변을 제공하고 검증 가능한 출처를 인용할 수 있어요.

사용 사례에 적합한 안전 테스트 수행하기

테스트는 견고하고 안전한 애플리케이션을 구축하는 핵심 부분이지만, 테스트의 범위·규모·전략은 다양해요. 예를 들어 재미로 만든 하이쿠 생성기는 법률 문서를 요약하고 계약서 초안 작성을 돕기 위해 설계된 애플리케이션보다 심각한 위험을 초래할 가능성이 낮아요. 하지만 하이쿠 생성기는 더 다양한 사용자가 사용할 수 있어 적대적 시도나 의도치 않은 유해 입력의 가능성이 더 클 수 있어요. 구현 컨텍스트도 중요해요. 예를 들어 어떤 조치가 취해지기 전에 인간 전문가가 출력을 검토하는 애플리케이션은 그러한 감독이 없는 동일한 애플리케이션보다 유해한 출력을 만들 가능성이 더 낮다고 볼 수 있어요.

상대적으로 위험이 낮은 애플리케이션에서도 출시 준비가 되었다고 느끼기 전에 변경과 테스트를 여러 번 반복하는 것은 드문 일이 아니에요. AI 애플리케이션에 특히 유용한 두 가지 종류의 테스트가 있어요.

안전 벤치마킹: 애플리케이션이 사용될 가능성이 있는 컨텍스트에서 어떻게 안전하지 않을 수 있는지를 반영하는 안전 지표를 설계한 다음, 평가 데이터셋을 사용해 애플리케이션이 해당 지표에서 얼마나 잘 수행하는지 테스트하는 방식이에요. 테스트 전에 안전 지표의 최소 허용 수준을 미리 생각하는 것이 좋은 관행이에요. 그래야 1) 기대치에 대해 테스트 결과를 평가할 수 있고, 2) 가장 관심 있는 지표를 평가하는 테스트를 기반으로 평가 데이터셋을 수집할 수 있으니까요.

고급 팁:

애플리케이션의 컨텍스트에 완전히 맞추려면 인간 평가자를 사용해 자체 테스트 데이터셋을 구축해야 할 가능성이 높으므로 "기성품(off the shelf)" 접근 방식에 지나치게 의존하지 않도록 주의하세요.
지표가 두 개 이상이라면 변경이 한 지표를 개선하면서 다른 지표를 해치게 될 때 어떻게 절충할지 결정해야 해요. 다른 성능 엔지니어링과 마찬가지로 평균 성능보다 평가 세트 전체의 최악의 경우 성능에 집중하고 싶을 수 있어요.
적대적 테스트: 애플리케이션을 적극적으로 깨뜨리려고 시도하는 방식이에요. 목표는 취약점을 식별해 상황에 맞게 해결하는 단계를 밟는 것이에요. 적대적 테스트는 애플리케이션에 대한 전문 지식을 가진 평가자에게 상당한 시간과 노력이 필요할 수 있지만, 더 많이 수행할수록 문제를 발견할 가능성이 커져요. 특히 드물게 발생하거나 애플리케이션을 반복 실행한 후에만 발생하는 문제를 발견할 가능성이 커져요.

적대적 테스트는 악의적이거나 의도치 않게 유해한 입력이 제공될 때 모델이 어떻게 동작하는지 배우려는 의도로 ML 모델을 체계적으로 평가하는 방법이에요.

입력이 안전하지 않거나 유해한 출력을 명확히 생성하도록 설계된 경우 입력은 악의적일 수 있어요. 예를 들어 텍스트 생성 모델에게 특정 종교에 대한 증오에 찬 다변(rant)을 생성하도록 요청하는 경우요.
입력 자체는 무해하지만 유해한 출력을 생성하는 경우 입력은 의도치 않게 유해할 수 있어요. 예를 들어 텍스트 생성 모델에게 특정 민족의 사람을 설명하도록 요청하고 인종차별적 출력을 받는 경우요.

적대적 테스트를 표준 평가와 구분하는 것은 테스트에 사용되는 데이터의 구성이에요. 적대적 테스트에서는 모델에서 문제가 있는 출력을 가장 많이 유발할 가능성이 있는 테스트 데이터를 선택해요. 이는 가능한 모든 유형의 피해에 대해 모델의 동작을 조사하는 것을 의미하며, 드물거나 특이한 예시와 안전 정책과 관련된 엣지 케이스를 포함해요. 또한 문장의 구조, 의미, 길이 같은 다양한 차원에서 다양성을 포함해야 해요. 테스트 데이터셋을 구축할 때 고려할 사항에 대한 자세한 내용은 Google의 공정성 관련 책임 있는 AI 실천을 참고할 수 있어요.

고급 팁:

애플리케이션을 깨뜨리려고 사람을 '레드 팀'으로 동원하는 전통적인 방법 대신 자동화된 테스트를 사용하세요. 자동화된 테스트에서 '레드 팀'은 테스트 중인 모델에서 유해한 출력을 유발하는 입력 텍스트를 찾는 또 다른 언어 모델이에요.

참고: LLM은 동일한 입력 프롬프트에 대해 때로 다른 출력을 생성하는 것으로 알려져 있어요. 문제가 있는 출력을 더 많이 잡으려면 여러 라운드의 테스트가 필요할 수 있어요.

문제 모니터링하기 (Monitor for problems)

아무리 많이 테스트하고 완화해도 완벽함을 보장할 수는 없으므로, 발생하는 문제를 어떻게 발견하고 처리할지 미리 계획하세요. 일반적인 접근 방식으로는 사용자가 피드백을 공유할 수 있는 모니터링 채널 설정(예: 엄지 위/아래 평가)과 다양한 사용자 집단에서 적극적으로 피드백을 구하는 사용자 연구 실행이 있어요. 특히 사용 패턴이 기대와 다를 때 유용해요.

고급 팁 (Advanced tips)

사용자가 AI 제품에 피드백을 주면, 예를 들어 프롬프트 튜닝에 더 나은 예시를 선택하는 데 도움을 줘서 시간이 지남에 따라 AI 성능과 사용자 경험을 크게 개선할 수 있어요. Google의 People and AI 가이드북의 피드백 및 제어 장은 피드백 메커니즘을 설계할 때 고려해야 할 핵심 사항을 강조해요.

다음 단계 (Next steps)

Gemini API에서 사용할 수 있는 조정 가능한 안전 설정에 대해 알아보려면 안전 설정 가이드를 참고하세요.
첫 프롬프트 작성을 시작하려면 프롬프팅 입문을 참고하세요.

안전 및 사실성 지침