프롬프트에 자동화된 테스트를 도입했습니다. 이제 프롬프트 변경 시 평가를 통과하지 못하면 CI가 실패합니다(모델 교체 시에도 적용). 작동 방식은 다음과 같습니다.

단위 테스트 → 통합 테스트 → 스모크 테스트 → 호환성 테스트로 이어지는 흐름이랑 똑같아.

모델 간 호환성 테스트:

이게 바로 사용자들이 실제로 겪는 '조용한 품질 저하'를 막아주는 핵심이야.

실제 상황을 가정해보자. 네 AI 글쓰기 툴이 현재 제공업체 모델에선 잘 돌아가. 근데 비용 아끼려고 무료 모델로 바꾸고 싶거나, 제공업체가 모델 버전을 없애버렸어. 그럼 프롬프트가 그대로 잘 작동할까? 사용자들이 여전히 쓸만한 결과물을 받을 수 있을까?

이 호출 한 번이면 답이 나와:

POST /api/v1/evaluations/cross-model-compare
{
  "prompt": "Generate a Python function to reverse a linked list",
  "models": [
    "meta-llama/llama-3.3-70b-instruct:free",
    "qwen/qwen3-coder:free",
    "google/gemini-2.0-flash-lite-001"
  ],
  "assertions": [
    {"type": "regex", "value": "def ", "weight": 0.5},
    {"type": "length-min", "value": "10", "weight": 0.5}
  ],
  "threshold": 0.8
}

결과:

{
  "results": [
    {"model": "meta-llama/llama-3.3-70b-instruct:free", "passed": true,  "overall_score": 0.91, "failure_reasons": []},
    {"model": "qwen/qwen3-coder:free",                  "passed": true,  "overall_score": 0.88, "failure_reasons": []},
    {"model": "google/gemini-2.0-flash-lite-001",       "passed": false, "overall_score": 0.61, "failure_reasons": ["regex 'def ' not found in output"]}
  ],
  "portable": false,
  "weakest_model": "google/gemini-2.0-flash-lite-001",
  "strongest_model": "meta-llama/llama-3.3-70b-instruct:free",
  "score_range": [0.61, 0.91]
}

portable: false가 떴다는 건, 그 프롬프트가 특정 모델에 종속되어 있다는 뜻이야. 즉, 구글 모델 쓰는 사용자들은 개판 난 결과물을 받게 된다는 거지. 사용자가 불평하기 전에, 미리 프롬프트를 수정할 수 있어.

컨텍스트 감지는 프롬프트에서 딱 한 번 실행되고 모든 모델 평가에 전달돼. 그래서 비교하는 동안 평가 기준이 일관되게 유지되지. 아무것도 저장되지 않으니 안심하고.

사용 사례:

• 비용 절감을 위해 모델을 교체할 때, 사용자한테 영향이 없는지 미리 확인
• 무료 티어 모델 풀을 대상으로 매주 회귀 테스트 (모델 업데이트마다 동작이 변하니까)
• 한 모델에 최적화된 프롬프트가 사용자들이 라우팅될 다른 모델들에서도 잘 작동하는지 검증
• 사용자에게 노출되어 품질 저하로 이어지기 전에, 모델별로 타는 프롬프트 패턴을 미리 잡아내기

컨텍스트별 단언 유형:

• 코드 생성: 언어 키워드(def, function, {)를 위한 regex, 구조화된 출력 변형을 위한 is-json, 지나치게 구체적인 프롬프트를 피하기 위한 length-min/length-max
• 이미지 생성: length-min/length-max (이미지 프롬프트는 최적의 길이 범위가 정해져 있음), 시각적 구체성을 위한 llm-rubric
• 메타 프롬프팅 / LLM 지시사항: 지시사항 문법 마커를 위한 regex, 명확성을 위한 llm-rubric
• 구조화된 출력 프롬프트: is-json이 핵심 관문

llm-rubric 어설션은 루브릭 텍스트를 위해 value 필드를 사용함. 어설션별 통과 임계값은 기본 0.6인데, 어설션 객체 안에 "threshold": 0.8을 넣어서 바꿀 수 있음. LLM 채점 편차를 줄이려고 평가기는 같은 모델로 샘플 3개를 돌려서 신뢰 구간이 포함된 평균 점수를 반환함. 그러니까 운 좋게 한 번 잘 나왔거나 망했다고 결과가 널뛰지 않는다는 소리임.

채점 모델 관련 참고:

요청에 있는 model 필드는 llm-rubric 어설션을 채점할 LLM을 정하는 거지, 프롬프트에 응답할 모델을 정하는 게 아님. 시스템이 감지된 컨텍스트에 따라 무료 채점기를 자동으로 고름. 코드 프롬프트는 코드 전문 모델로, 창의적인 프롬프트는 일반 모델로 보내는 식임. 물론 직접 바꿀 수도 있지만, 기본값은 다 무료임. meta-llama/llama-3.3-70b-instruct:free랑 qwen/qwen3-coder:free 둘 다 비용 안 드는 티어에 있음.

이게 저번 주에 브라이언 암스트롱이 쓴 글이랑 같은 원리임. "인간이 모델을 고를 게 아니라 AI가 이 작업을 자동화해야 한다." 우리 ContextAwareEvaluatorSelector가 딱 그 짓을 함. 컨텍스트 → 최적의 무료 모델, 수동 설정 따위 필요 없음.

이 시스템이 이미 하고 있는데 아무도 언급 안 하는 것들:

사용량은 늘어나는데 AI 비용은 그대로 유지하는 법에 대한 암스트롱의 글을 읽어보면, 우리 옵티마이저가 이미 그가 말한 5가지 원칙을 다 구현해 놨음:

• 더 나은 기본값: 무료 모델이 기본값이고 컨텍스트 유형에 따라 자동 선택됨. 요청별로 바꾸거나 계정 설정에서 변경 가능.
• 더 나은 라우팅: 간단한 프롬프트는 규칙 기반, 중간급은 하이브리드, 복잡한 건 LLM 전용으로 처리. 비용만큼 가치가 있을 때만 최상위 모델 사용.
• 더 나은 캐싱: 2단계 캐시(메타 프롬프트 및 전체 결과), 응답 메타데이터에서 캐시 적중 여부 추적.
• 컨텍스트 최적화: 512MB 메모리 제한으로 레이지 로딩과 모델 자동 언로드를 강제함.
• 더 나은 가시성: 분석 엔드포인트가 요청별 라우팅 결정을 추적함.

인프라가 이미 빡센 작업은 다 해놓음. 테스트 계층이 이 루프를 완성하는 거임. 최적화된 프롬프트가 퇴보하는 걸 잡아내지 못하면 안정적인 라우팅은 불가능하니까. 그리고 이식성 테스트 없이는 모델별 퇴보를 잡아낼 수도 없음.

전체 그림:

테스트가 품질 루프를 완성함:

컨텍스트 감지 → 최적화 → 평가 → 템플릿 내 관리 → 변경 시 테스트 → 이식성 검증 → 컨텍스트 재감지

고정된 엔드포인트가 있는 파이프라인이 아님. 사용자가 보기 전에 퇴보를 잡아내는 루프임. 모델 변경 때문에 생기는, 당신이 미처 몰랐던 문제들까지 다 잡아냄.

Prompt Optimizer — MCP 네이티브, 모델 중립적, 무료 티어 제공.