안전 및 사실성 가이드

생성형 인공지능 모델은 강력한 도구이지만 한계가 있습니다. 다양한 용도로 사용할 수 있다는 장점은 부정확하거나 편향되거나 불쾌감을 주는 출력과 같은 예기치 않은 결과를 초래할 수 있습니다. 이러한 출력으로 인한 피해 위험을 제한하려면 후처리 및 엄격한 수동 평가가 필수적입니다.

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

대규모 언어 모델 (LLM)이 매우 유용한 이유는 다양한 언어 작업을 처리할 수 있는 창의적인 도구이기 때문입니다. 하지만 대규모 언어 모델은 불쾌감을 주거나 민감하지 않거나 사실에 맞지 않는 텍스트를 포함하여 예상치 못한 출력을 생성할 수 있습니다. 또한 이러한 모델의 놀라운 다양성으로 인해 발생할 수 있는 바람직하지 않은 출력의 유형을 정확히 예측하기가 어렵습니다. Gemini API는 Google's AI 원칙을 염두에 두고 설계되었지만, 이러한 모델을 책임감 있게 적용하는 것은 개발자의 몫입니다. 개발자가 안전하고 책임감 있는 애플리케이션을 만들 수 있도록 Gemini API에는 기본 제공 콘텐츠 필터링과 4가지 유해성 측면에서 조정 가능한 안전 설정이 있습니다. 자세한 내용은 안전 설정 가이드를 참고하세요. 또한 사실성을 개선하기 위해 Google 검색을 사용한 그라운딩을 제공하지만, 사용 사례가 정보 검색이 아닌 더 창의적인 개발자의 경우 이 기능을 사용 중지할 수 있습니다.

이 문서는 LLM을 사용할 때 발생할 수 있는 몇 가지 안전 위험을 소개하고 새로운 안전 설계 및 개발 권장사항을 추천하기 위한 것입니다. (법률 및 규정으로 인해 제한이 적용될 수도 있지만 이러한 고려사항은 이 가이드의 범위를 벗어납니다.)

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

• 애플리케이션의 안전 위험 이해
• 안전 위험을 완화할 수 있는 조정 고려
• 사용 사례에 적합한 안전 테스트 수행
• 사용자 의견을 요청하고 사용량 모니터링

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

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

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

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

안전 및 사실성 위험을 완화할 수 있는 조정 고려

이제 위험을 이해했으므로 위험을 완화하는 방법을 결정할 수 있습니다. 우선순위를 지정할 위험과 위험을 방지하기 위해 수행해야 하는 작업의 양을 결정하는 것은 소프트웨어 프로젝트에서 버그를 분류하는 것과 마찬가지로 중요한 결정입니다. 우선순위를 정한 후 가장 적절한 완화 유형을 생각해 볼 수 있습니다. 간단한 변경으로도 위험을 줄일 수 있습니다.

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

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

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

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

  고급 도움말

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

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

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

• 유해할 수 있는 대답이 표시될 가능성을 줄이도록 유해한 콘텐츠 안전 설정을 조정합니다. Gemini API는 프로토타입 제작 단계에서 조정하여 애플리케이션에 더 제한적인 안전 구성이 필요한지 아니면 덜 제한적인 안전 구성이 필요한지 결정할 수 있는 안전 설정을 제공합니다. 5가지 필터 카테고리에서 이러한 설정을 조정하여 특정 유형의 콘텐츠를 제한하거나 허용할 수 있습니다. Gemini API를 통해 사용할 수 있는 조정 가능한 안전 설정에 관한 자세한 내용은 안전 설정 가이드를 참고하세요.

• Google 검색을 사용한 그라운딩을 사용 설정하여 잠재적인 사실 부정확성 또는 환각을 줄입니다. 많은 AI 모델은 실험용이며 사실에 맞지 않는 정보를 제공하거나 환각을 일으키거나 기타 문제가 있는 출력을 생성할 수 있습니다. Google 검색을 사용한 그라운딩 기능은 Gemini 모델을 실시간 웹 콘텐츠에 연결하며 사용 가능한 모든 언어로 작동합니다. 이를 통해 Gemini는 모델의 지식 단절점을 넘어 더 정확한 대답을 제공하고 검증 가능한 출처를 인용할 수 있습니다.

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

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

상대적으로 위험이 낮은 애플리케이션의 경우에도 출시할 준비가 되었다고 확신하기 전에 여러 번 변경하고 테스트하는 것이 일반적입니다. AI 애플리케이션에는 두 가지 유형의 테스트가 특히 유용합니다.

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

  고급 팁

  • 애플리케이션의 컨텍스트에 완전히 적합하도록 인적 평가자를 사용하여 자체 테스트 데이터 세트를 빌드해야 할 가능성이 높으므로 '기성품' 접근 방식에 과도하게 의존하지 않도록 주의하세요.
  • 측정항목이 두 개 이상인 경우 변경으로 인해 한 측정항목이 개선되고 다른 측정항목이 저하되는 경우 어떻게 절충할지 결정해야 합니다. 다른 성능 엔지니어링과 마찬가지로 평가 세트에서 평균 성능보다는 최악의 성능에 집중하는 것이 좋습니다.

• 적대적 테스트 에는 애플리케이션을 사전에 중단하려고 시도하는 것이 포함됩니다. 목표는 약점을 파악하여 적절한 조치를 취할 수 있도록 하는 것입니다. 적대적 테스트는 애플리케이션에 관한 전문 지식을 갖춘 평가자의 상당한 시간과 노력이 필요할 수 있지만, 더 많이 수행할수록 문제를 발견할 가능성이 높아집니다. 특히 애플리케이션을 반복 실행한 후에만 발생하는 문제의 경우 더욱 그렇습니다.

  • 적대적 테스트는 악의적이거나 의도치 않게 유해한 입력이 제공되었을 때 ML 모델이 어떻게 작동하는지 파악하기 위한 목적으로 ML 모델을 체계적으로 평가하는 방법입니다.
    • 입력이 안전하지 않거나 유해한 출력을 생성하도록 명확하게 설계된 경우 입력이 악의적일 수 있습니다. 예를 들어 텍스트 생성 모델에 특정 종교에 대한 증오심 표현을 생성하도록 요청하는 것입니다.
    • 입력 자체는 무해하지만 유해한 출력을 생성하는 경우 입력이 의도치 않게 유해합니다. 예를 들어 텍스트 생성 모델에 특정 민족의 사람을 설명하도록 요청하고 인종 차별적인 출력을 받는 것입니다.
  • 적대적 테스트와 표준 평가를 구분하는 것은 테스트에 사용되는 데이터의 구성입니다. 적대적 테스트의 경우 모델에서 문제가 있는 출력을 생성할 가능성이 가장 높은 테스트 데이터를 선택합니다. 즉, 안전 정책과 관련된 드물거나 특이한 예시와 엣지 케이스를 포함하여 발생할 수 있는 모든 유형의 피해에 대해 모델의 동작을 조사하는 것입니다. 또한 구조, 의미, 길이와 같은 문장의 다양한 측면에서 다양성을 포함해야 합니다. 테스트 데이터 세트를 빌드할 때 고려해야 할 사항에 관한 자세한 내용은 Google's Responsible AI practices in fairness 를 참고하세요.

    고급 팁

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

문제 모니터링

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

다음 단계

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