안전 안내

생성형 인공지능 모델은 강력한 도구이지만 한계가 있는 것은 아닙니다. 다기능성 및 적용 가능성으로 인해 때때로 부정확하거나 편향된 출력 또는 불쾌감을 주는 출력과 같은 예상치 못한 출력이 발생할 수 있습니다. 이러한 출력으로 인한 피해 위험을 최소화하기 위해서는 후처리와 엄격한 수동 평가가 필수적입니다.

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

대규모 언어 모델 (LLM)이 매우 유용한 이유 중 하나는 다양한 언어 작업을 처리할 수 있는 창의적인 도구라는 점입니다. 하지만 이는 대규모 언어 모델이 불쾌감을 주거나 무분별하거나 사실이 아닌 텍스트를 비롯하여 사용자가 예상하지 못한 출력을 생성할 수 있다는 의미이기도 합니다. 게다가 이러한 모델의 놀라운 다양성으로 인해 어떤 종류의 바람직하지 않은 출력이 생성될 수 있는지 정확하게 예측하기 어렵습니다. Gemini API는 Google의 AI 원칙을 염두에 두고 설계되었지만 이러한 모델을 책임감 있게 적용하는 것은 개발자의 책임입니다. 개발자가 안전하고 책임감 있는 애플리케이션을 만들 수 있도록 Gemini API에는 몇 가지 기본 제공 콘텐츠 필터링과 4가지 위험 측면에서 조정 가능한 안전 설정이 있습니다. 자세한 내용은 안전 설정 가이드를 참고하세요.

이 문서에서는 LLM을 사용할 때 발생할 수 있는 몇 가지 안전 위험을 소개하고 새로운 안전 설계 및 개발 권장사항을 권장합니다. 법률 및 규정에 따라 제한사항이 적용될 수 있지만 이러한 고려사항은 이 가이드의 범위를 벗어납니다.

LLM으로 애플리케이션을 빌드할 때는 다음 단계를 따르는 것이 좋습니다.

• 애플리케이션의 안전 위험 이해
• 안전 위험 완화를 위한 조정 고려
• 사용 사례에 적합한 안전 테스트 실행
• 사용자 의견 요청 및 사용 모니터링

애플리케이션에 적합한 성능에 도달할 때까지 조정 및 테스트 단계를 반복해야 합니다.

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

이러한 맥락에서 안전은 예를 들어 고정관념을 조장하는 악의적인 언어나 콘텐츠를 생성하여 사용자에게 해를 끼치지 않도록 하는 LLM의 기능으로 정의됩니다. Gemini API를 통해 제공되는 모델은 Google의 AI 원칙을 염두에 두고 설계되었으며 사용 시 생성형 AI 금지된 사용 정책이 적용됩니다. 이 API는 유해한 언어 및 증오심 표현과 같은 일반적인 언어 모델 문제를 해결하고 고정 관념을 포용하고 방지하려고 노력하는 데 도움이 되는 안전 필터를 기본 제공합니다. 그러나 애플리케이션마다 사용자에게 다른 위험이 발생할 수 있습니다. 따라서 애플리케이션 소유자는 사용자와 애플리케이션이 초래할 수 있는 잠재적 피해를 파악하고 애플리케이션이 LLM을 안전하고 책임감 있게 사용하도록 해야 합니다.

이 평가의 일환으로 피해가 발생할 가능성을 고려하고 그 심각성 및 완화 단계를 결정해야 합니다. 예를 들어 사실에 입각한 이벤트를 기반으로 에세이를 생성하는 앱은 엔터테인먼트를 위한 허구의 이야기를 생성하는 앱보다 잘못된 정보를 방지하는 데 더 신중을 기해야 합니다. 잠재적인 안전 위험을 알아보기 시작하는 좋은 방법은 최종 사용자 및 애플리케이션 결과의 영향을 받을 수 있는 다른 사용자를 조사하는 것입니다. 여기에는 앱 도메인에서 최신 연구를 조사하거나, 사람들이 유사한 앱을 사용하는 방식을 관찰하거나, 사용자 연구, 설문조사를 실시하거나, 잠재적 사용자와 비공식적인 인터뷰를 진행하는 등 다양한 형태가 있습니다.

안전 위험을 완화하기 위한 조정 고려하기

이제 위험을 이해했으므로 위험을 완화하는 방법을 결정할 수 있습니다. 소프트웨어 프로젝트에서 버그를 분류하는 것과 마찬가지로 우선순위를 지정할 위험과 이를 방지하기 위해 취할 조치를 결정하는 것은 매우 중요한 결정입니다. 우선순위를 결정했다면 가장 적절한 완화 유형에 대해 생각해 볼 수 있습니다. 종종 단순한 변경으로 차이를 만들고 위험을 줄일 수 있습니다.

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

• 애플리케이션 컨텍스트에서 허용되는 사항을 더 잘 반영하도록 모델 출력 조정 조정하면 모델의 출력을 더 예측 가능하고 일관되게 만들 수 있으므로 특정 위험을 완화하는 데 도움이 될 수 있습니다.
• 안전한 출력을 제공하는 입력 방법 제공 LLM에 제공하는 정확한 입력에 따라 출력 품질이 달라질 수 있습니다. 입력 프롬프트를 실험하여 사용 사례에서 가장 안전하게 작동하는 것을 찾는 것은 노력을 기울일 가치가 있습니다. 그러면 이를 용이하게 하는 UX를 제공할 수 있습니다. 예를 들어 사용자가 입력 프롬프트의 드롭다운 목록에서만 선택하도록 제한하거나 애플리케이션 컨텍스트에서 안전하게 작동하는 것으로 확인된 설명 문구와 함께 팝업 제안을 제공할 수 있습니다.

• 안전하지 않은 입력을 사용자에게 표시하기 전에 차단하고 출력을 필터링합니다. 간단한 상황에서는 차단 목록을 사용하여 프롬프트나 대답에서 안전하지 않은 단어나 문구를 식별 및 차단하거나 검토자가 이러한 콘텐츠를 직접 변경하거나 차단하도록 요구할 수 있습니다.

• 학습된 분류기를 사용하여 각 프롬프트에 잠재적 피해 또는 적대적 신호로 라벨을 지정합니다. 그런 다음 감지된 피해 유형에 따라 요청을 처리하는 방법에 대해 다양한 전략을 사용할 수 있습니다. 예를 들어 입력의 본질적으로 지나치게 적대적이거나 악의적인 경우 입력을 차단하고 사전 스크립트화된 응답을 대신 출력할 수 있습니다.

  고급 도움말

  • 신호에 따라 출력이 유해하다고 판단하는 경우 애플리케이션은 다음 옵션을 사용할 수 있습니다.
    • 오류 메시지 또는 사전 스크립트 처리된 출력을 제공합니다.
    • 동일한 프롬프트에서 다른 출력이 나올 수 있으므로 대체 안전 출력이 생성되는 경우를 대비하여 프롬프트를 다시 시도하세요.

• 각 사용자에게 고유 ID를 할당하고 특정 기간에 제출할 수 있는 사용자 쿼리 양을 제한하는 등 고의적인 오용을 방지하기 위한 보호 장치를 마련합니다. 또 다른 보호 장치는 가능한 프롬프트 삽입으로부터 보호하는 것입니다. SQL 삽입과 마찬가지로 프롬프트 삽입은 악의적인 사용자가 모델의 출력을 조작하는 입력 프롬프트를 설계할 수 있는 방법입니다. 예를 들어 모델이 이전 예시를 무시하도록 지시하는 입력 프롬프트를 전송할 수 있습니다. 의도적인 오용에 대한 자세한 내용은 생성형 AI 금지된 사용 정책을 참조하세요.

• 본질적으로 위험성이 낮은 것으로 기능을 조정합니다. 범위가 더 좁거나 (예: 텍스트 구절에서 키워드 추출) 사람의 감독이 더 많이 이루어지는 작업 (예: 사람이 검토할 짧은 형식의 콘텐츠를 생성하는 작업)은 대개 위험도가 낮습니다. 예를 들어 이메일 답장을 처음부터 작성하는 애플리케이션을 만드는 대신 개요를 확장하거나 대체 문구를 제안하도록 제한할 수 있습니다.

사용 사례에 적합한 안전 테스트 실행

테스트는 강력하고 안전한 애플리케이션을 빌드하는 데 핵심적인 부분이지만 테스트의 범위, 범위, 전략은 다양합니다. 예를 들어 단순한 재미를 위한 하이쿠 생성기는 법률 회사에서 법률 문서를 요약하고 계약서 초안을 작성하는 데 사용하도록 설계된 애플리케이션보다 덜 심각한 위험을 초래할 가능성이 높습니다. 그러나 하이쿠 생성기는 더 다양한 사용자가 사용할 수 있으므로 적대적인 시도 또는 의도치 않은 유해한 입력의 가능성이 더 클 수 있습니다. 구현 상황도 중요합니다. 예를 들어, 조치를 취하기 전에 전문가의 검토를 거친 출력이 있는 애플리케이션은 이러한 감독이 없는 동일한 애플리케이션보다 유해한 출력을 생성할 가능성이 낮다고 간주될 수 있습니다.

상대적으로 위험이 낮은 애플리케이션에서도 출시할 준비가 되었다는 확신을 얻기 전에 변경 및 테스트를 여러 차례 거치는 것은 드문 일이 아닙니다. 두 가지 유형의 테스트는 AI 애플리케이션에 특히 유용합니다

• 안전 벤치마킹에는 사용 가능성과 관련하여 애플리케이션이 안전하지 않을 수 있는 방식을 반영하는 안전 측정항목을 설계한 다음 평가 데이터 세트를 사용하여 측정항목에 대한 애플리케이션의 성능을 테스트하는 작업이 포함됩니다. 1) 이러한 기대치에 따라 테스트 결과를 평가하고 2) 가장 중요한 측정항목을 평가하는 테스트를 기반으로 평가 데이터 세트를 수집할 수 있도록 테스트하기 전에 허용 가능한 최소 수준의 안전 측정항목을 고려하는 것이 좋습니다.

  고급 도움말

  • 애플리케이션의 컨텍스트에 완전히 적합하게 하려면 평가자를 통해 자체 테스트 데이터 세트를 빌드해야 할 수 있으므로 '즉시 사용 가능한' 접근 방식에 너무 의존하지 않도록 주의하세요.
  • 측정항목이 두 개 이상인 경우 변경사항이 한 측정항목의 개선으로 이어지고 다른 측정항목에 악영향을 미칠 경우 어떻게 절충할 방법을 결정해야 합니다. 다른 성능 엔지니어링과 마찬가지로 평균 성능보다는 평가 세트 전반에서 최악의 성능에 초점을 맞추는 것이 좋습니다.

• 적대적 테스트에는 애플리케이션을 중단하기 위한 사전 시도가 포함됩니다. 목표는 약점을 파악하여 적절한 조치를 취할 수 있도록 하는 것입니다. 적대적 테스트에는 애플리케이션에 대한 전문 지식을 갖춘 평가자가 상당한 시간과 노력을 들여야 할 수 있습니다. 하지만 테스트를 많이 할수록 문제를 발견할 가능성이 높아지며, 특히 애플리케이션을 드물게 또는 반복 실행한 후에만 발생하는 문제를 발견할 가능성이 커집니다.

  • 적대적 테스트는 악의적이거나 의도치 않게 유해한 입력이 제공되었을 때 모델이 어떻게 동작하는지 알아보기 위해 ML 모델을 체계적으로 평가하는 방법입니다.
    • 텍스트 생성 모델에 특정 종교에 관한 혐오 발언을 생성하도록 요청하는 등 입력이 안전하지 않거나 유해한 출력을 생성하도록 명확하게 설계된 경우 악의적인 입력일 수 있습니다.
    • 입력 자체가 무해할 수 있지만 텍스트 생성 모델에 특정 인종의 사람을 설명하도록 요청하고 인종 차별적인 결과를 얻는 등 입력은 유해한 출력을 생성하는 경우 의도치 않게 유해합니다.
  • 적대적 테스트와 표준 평가의 차이점은 테스트에 사용되는 데이터의 구성입니다. 적대적 테스트의 경우 모델에서 문제가 있는 출력을 얻을 가능성이 가장 높은 테스트 데이터를 선택합니다. 즉, 드물거나 특이한 예 및 안전 정책과 관련된 극단적인 사례를 포함하여 가능한 모든 유형의 피해에 대해 모델의 동작을 프로브해야 합니다. 또한 구조, 의미, 길이와 같은 문장의 다양한 차원의 다양성도 포함해야 합니다. 테스트 데이터 세트를 빌드할 때 고려해야 할 사항에 대한 자세한 내용은 Google의 책임감 있는 AI 공정성 관행을 참조하세요.

    고급 도움말

    • '레드팀'에 사람들을 선발하여 애플리케이션 중단을 시도하는 기존의 방법 대신 자동 테스트를 사용하세요. 자동화된 테스트에서 '레드팀'은 테스트 중인 모델에서 유해한 출력을 유도하는 입력 텍스트를 찾는 또 다른 언어 모델입니다.

문제 모니터링

아무리 테스트를 많이 하고 완화하더라도 완벽함을 보장할 수는 없으므로 발생하는 문제를 발견하고 처리할 방법을 미리 계획해야 합니다. 일반적인 접근 방법으로는 사용자가 의견을 공유할 수 있도록 모니터링되는 채널(예: 좋아요/싫어요 평가)을 설정하고 다양한 사용자로부터 사전에 의견을 요청하는 사용자 연구를 실행하는 것이 포함됩니다. 특히 사용 패턴이 예상과 다른 경우에 유용합니다.

다음 단계

• Gemini API를 통해 사용할 수 있는 조정 가능한 안전 설정에 대해 자세히 알아보려면 안전 설정 가이드를 참고하세요.
• 첫 번째 프롬프트 작성을 시작하려면 프롬프팅 소개를 참조하세요.