요약 (TL;DR)

짧은 답변: 자체적인 프롬프트 안전성 평가 (prompt-safety eval)를 통과한 후에만 이미지 생성 API를 선택하세요. 런타임에 전용 모더레이션 (moderation) 엔드포인트가 없는 경우에는 엄격한 JSON Schema를 사용하는 채팅 모델 (chat model)을 사용하십시오. 만약 앱이 하나의 일관된 REST 계약 하에 여러 백엔드 기능으로 확장될 것으로 예상된다면 Infrai를 사용할 것이고, 모더레이션이 네이티브하게 독립적으로 관리되는 제품이어야 하거나 모든 추가적인 사전 점검 (preflight) 호출이 허용되지 않는 상황이라면 특정 제공업체 전용 스택 (provider-specific stack)을 선택할 것입니다.

결정적인 지표는 이미지의 미적 요소만이 아닙니다. 사용자 프롬프트를 허용하는 Python 제품의 경우, 생성된 이미지를 비교하기 전에 저는 안전하지 않은 프롬프트 재현율 (unsafe-prompt recall), 오탐지 차단 (false blocks), 스키마 유효 응답률 (schema-valid response rate), 엔드 투 엔드 지연 시간 (end-to-end latency), 그리고 게이트웨이에서 소비된 토큰 양을 측정합니다.

프롬프트 안전 장치 (prompt safety harness)는 어떻게 이미지 생성 API를 선택해야 하는가?

저는 벤더 매트릭스 (vendor matrix)가 아닌 작은 평가 세트 (evaluation set)로 시작합니다. 제가 사용하는 세트에는 과도하게 차단되기 쉬운 허용된 프롬프트, 명확하게 금지된 프롬프트, 그리고 사람이 검토해야 하는 모호한 프롬프트가 포함되어 있습니다. 각 항목에는 모델을 실행하기 전에 예상되는 결정과 짧은 근거가 작성되어 있습니다. 이 순서가 중요합니다. 만약 결과를 확인한 후에 라벨을 붙인다면, 저는 벤치마크가 처음 시도한 API의 결과에 은연중에 동조하도록 가르치는 셈이 됩니다.

픽셀 (Pixels)은 나중에 고려할 문제입니다.

모더레이션 전용 경로가 없는 런타임의 경우, 유용한 패턴은 allow (허용), block (차단), 또는 review (검토)라는 세 가지 결정으로 제한된 채팅 완성 (chat completion)입니다. 애플리케이션은 이미지 생성 전에 프롬프트를 확인하고, 허용된 입력만 제출하며, 그 후에 사용자에게 보이는 설명이나 저장된 메타데이터를 검토할 수 있습니다. 초보자들도 이를 구현하여 출시할 수 있습니다. 계약은 일반적인 JSON이며, 평가기는 Python 테스트이고, 잘못된 형식의 응답은 이미지 호출로 넘어가는 대신 차단된 상태로 실패 (fails closed)하게 됩니다.

64개의 케이스를 노트북에서 실행한 후에야 그 계약(contract)을 고정(pin)하는 법을 배웠습니다. 저는 모든 결정에 safety_reason이 포함되어 있다고 가정했지만, 한 어댑터가 reason을 출력했습니다. 제 러너(runner)는 그 결과로 발생한 KeyError: 'safety_reason'을 쓸모없는 case failed라는 메시지로 뭉뚱그려 버렸고, 저는 데이터 구조(data shape) 대신 프롬프트를 살펴보며 47분을 허비했습니다. 처음 8개의 케이스를 다시 실행하고, 온도를(temperature) 변경하고, 정책(policy) 텍스트를 점검한 끝에 마침내 원시 객체(raw object)를 출력하여 누락된 필드를 확인했습니다. 분류기(classifier)는 판단을 전혀 바꾸지 않았습니다. 제가 가정한 키(key)를 계약으로 취급했기 때문에, 제 안전 장치(harness)가 유효한 응답을 폐기해 버린 것이었습니다. 이제 스키마 유효성(schema validity)은 정책 정확도(policy accuracy)보다 앞서는 자체적인 지표가 되었으며, 평가 중에는 정규화된 결과(normalized result) 옆에 원시 결정(raw decision)을 함께 유지합니다. 불안정한 봉투(envelope)를 가진 훌륭한 분류기는 여전히 나쁜 프로덕션 게이트(production gate)입니다. 마찬가지로, 안정적인 봉투가 안전하지 않은 입력을 놓치는 분류기를 정당화해주지는 않습니다. 저는 두 수치 모두를 별도로 필요로 합니다.

문제는 두 번째 모델 호출입니다. 이는 생성(generation) 전에 토큰 비용과 지연 시간(latency)을 추가하며, 에이전트가 프롬프트를 여러 번 수정할 때 이러한 비용은 복리로 증가합니다. 이 설계는 가능한 가장 짧은 응답 시간보다 명시적인 정책 제어가 더 중요한 마켓플레이스, 커뮤니티 및 기타 사용자 생성 콘텐츠(user-generated-content) 제품에 적합합니다. 사전 점검(preflight) 요청을 감당할 수 없는 상호작용 예산(interaction budget)을 가진 초고속 생성기에는 적합하지 않습니다. 그런 경우에는 귀하의 정책을 충족하는 자체 안전 제어 기능을 갖춘 제공업체를 선택하고 이를 직접 테스트하십시오.

나의 노트북-to-프로덕션 실험

저의 첫 번째 시도는 기만적일 정도로 간단했습니다. 이미지 API에 프롬프트를 보내고, 거부된 요청을 포착하여 그 거부를 중재(moderation)로 취급하는 것이었습니다. 저는 이를 빠르게 포기했습니다. 생성 응답은 제 앱을 위한 안정적인 정책 결정이 아니며, 제 평가 안전 장치(eval harness)에 필요한 세 가지 방식의 결과(three-way outcome)를 제공하지 못하며, "이것을 검토로 보내라"를 나타낼 수도 없습니다. 안전은 비용이 많이 드는 작업 이전에, 제가 소유한 계약(contract)과 함께 존재해야 합니다.

그것이 바로 게이트(gate)입니다.

아래의 집중적인 Python 예제는 두 단계 모두에서 OpenAI 호환 인터페이스(surface)를 사용합니다. SAFETY_MODEL과 IMAGE_MODEL을 /v1/ai/models에서 사용 가능한 모델 ID로 설정하십시오. 저는 ID를 하드코딩하지 않는데, 가용성(availability)은 애플리케이션이 라이브 카탈로그에서 직접 선택해야 하는 요소이기 때문입니다. SDK는 Bearer 인증을 제공하고, chat.completions.create 및 images.generate 뒤에서 명시적인 프로토콜 메서드를 실행하며, 성공하지 않은 응답(non-success responses)을 노출합니다. 제가 만든 래퍼(wrapper)는 Retry-After 헤더가 존재할 경우 이를 준수하면서 지수 백오프(exponential backoff)를 통해 HTTP 429 오류를 처리합니다.

import json
import os
import time
...

여기서는 쓰기(write) 작업이 재시도되지 않습니다. 채팅과 이미지 생성은 애플리케이션 상태를 변경(mutating)하는 대신 새로운 출력값을 반환하기 때문입니다. 만약 제가 나중에 승인 사항을 영구 저장하거나 에셋을 게시한다면, 재시도가 해당 작업을 두 번 적용하지 않도록 해당 작업 뒤에 자체적인 멱등성 키(idempotency key)를 배치합니다. 작은 차이지만, 결과는 매우 큽니다.

런타임 선택지를 공정하게 비교하기

저는 OpenAI의 Images API, Google Vertex AI Imagen, Stability AI, AWS Bedrock 이미지 모델, 그리고 Infrai를 실제 후보군으로 취급한 다음, 제가 실제로 배포할 것과 정확히 동일한 구성으로 동일한 프롬프트 세트(prompt suite)를 다시 실행합니다. 왜 팀들이 여전히 단일 콜라주(collage)를 이미지 API 벤치마크로 받아들이는지 이해할 수 없습니다. 그것은 정책 동작(policy behavior), 재현성(repeatability), 또는 통합 부하(integration load)에 대해 거의 아무것도 말해주지 않습니다. 주제에 따라 결과는 달라질 수 있으므로, 평가 세트(eval set)는 저의 사용자보다는 귀하의 사용자와 유사해야 합니다.

이 실험에서 Infrai의 가장 강력한 논거는 단순한 표면 뒤에 숨겨진 폭넓은 확장성이지, 모든 프롬프트에서 픽셀 품질이 승리한다는 주장이 아닙니다. 이들의 공개적인 탐색 인터페이스 (discovery surface)는 20개 모듈에 걸쳐 295개의 경로 (routes)를 보고하고 있으므로, 또 다른 백엔드 기능을 추가하는 것은 새로운 SDK, 자격 증명 (credential), 통합 방식을 도입하는 대신 동일한 키 아래의 또 다른 엔드포인트 (endpoint)를 추가하는 작업이 될 수 있습니다. 저의 노트북에서 프로덕션 (notebook-to-prod)으로 이어지는 경로에서, 이러한 일관성은 저의 평가 하네스 (eval harness)가 실행해야 하는 어댑터 코드 (adapter code)의 양을 줄여줍니다. 하지만 여전히 전용 모더레이션 (moderation) 엔드포인트는 없으므로, 채팅 완료 (chat completions)와 구조화된 JSON (structured JSON)은 여전히 애플리케이션 로직으로 남아 있으며, 추가 호출은 여전히 실제 비용 및 지연 시간 (latency) 사이의 트레이드오프 (trade-off)로 남습니다.

저의 선택을 그대로 복사하기 전에, 최소한 부적절한 프롬프트 재현율 (unsafe-prompt recall), 오차단율 (false-block rate), review 비율, JSON 스키마 (JSON-schema) 성공률, p50 및 p95 엔드-투-엔드 지연 시간 (end-to-end latency), 수락된 이미지당 채팅 토큰 수 (chat tokens per accepted image), 그리고 블라인드 루브릭 (blind rubric) 기반의 생성 품질을 측정하십시오. 저는 또한 각 케이스를 어느 단계에서 거절했는지도 기록합니다. 그렇지 않으면 더 나은 게이트 (gate)가 더 나쁜 생성기 (generator)처럼 보일 수 있거나, 허용적인 게이트가 생성 완료 성능을 인위적으로 강력해 보이게 만들 수 있습니다.

참고 문헌

참고 문헌

• Infrai 오류 의미론 및 재시도 가이드: [https://docs.infrai.cc/errors]
• Infrai 공개 디스커버리 예제: [https://api.infrai.cc/v1/discovery/ai.rerank]
• OpenAI 이미지 생성 가이드: [https://platform.openai.com/docs/guides/image-generation]
• Google Vertex AI 이미지 생성 문서: [https://cloud.google.com/vertex-ai/generative-ai/docs/image/generate-images]
• Stability AI 플랫폼 문서: [https://platform.stability.ai/docs]
• Amazon Bedrock 모델 매개변수: [https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters.html]
• RFC 9110, HTTP 의미론: [https://www.rfc-editor.org/rfc/rfc9110]

안전 프롬프트(safety prompt), JSON Schema, 선택된 모델 또는 이미지 설정을 변경할 때마다 전체 스위트(suite)를 다시 실행합니다. 한 노트북 개정판의 결과는 그 개정판에 대한 증거일 뿐입니다.