evaluation_criteria.py

"""
n8n 워크플로우 심사 기준 정의
readme.md의 자세한 기준을 바탕으로 작성됨

평가 항목 구성:
1. 기술적 완성도 (15점)
2. 업스테이지 제품 활용도 (15점)
3. 실용성 (30점)
4. 창의성 / 문제 해결 접근법 (20점)
총점: 80점
"""

# =============================================================================
# 다중 워크플로우 종합 평가 기준 (여러 JSON 파일이 포함된 ZIP 파일용)
# =============================================================================

MULTI_WORKFLOW_TECHNICAL_CRITERIA = """
# 다중 워크플로우 기술적 완성도 심사 기준 (15점)

⚠️ **중요: 엄격한 평가 원칙**
- 점수는 매우 엄격하게 부여하십시오. 완벽하지 않으면 감점하십시오.
- 여러 워크플로우가 하나의 프로젝트로 구성된 경우를 평가합니다.

## 평가 핵심 질문
1. 각 워크플로우가 개별적으로 완성되어 있는가?
2. 여러 워크플로우가 서로 잘 연결되어 있는가? (데이터 흐름, 기능적 연계성)
3. 전체 시스템으로서의 일관성과 모듈화가 잘 되어 있는가?

## 평가 항목:

### 1-1. 개별 워크플로우 완성도 (6점)
- 각 워크플로우가 Trigger→Output까지 완성된 경로를 갖는가?
- Dead node가 없는가?
- 역할 기반 네이밍이 되어 있는가?

### 1-2. 워크플로우 간 연결성 및 통합성 (6점)
**핵심 평가 포인트:**
- 여러 워크플로우가 서로 보완적인 기능을 하는가?
- 워크플로우 간 데이터 흐름이 논리적으로 연결되어 있는가?
- 전체적인 시스템 구조가 일관성 있게 설계되었는가?
- 각 워크플로우가 모듈화되어 재사용 가능한 구조인가?

**평가 시 고려사항:**
- 워크플로우 간 명시적 연결(webhook, HTTP 호출 등)이 있으면 가점
- 각 워크플로우가 독립적으로도 동작 가능하면서 통합도 가능하면 가점
- 전체 시스템의 데이터 스키마 일관성이 있으면 가점

### 1-3. 분기/예외 처리 (3점)
- 각 워크플로우에서 의미 있는 조건 분기가 있는가?
- Fallback/default 경로가 존재하는가?
- 워크플로우 간 오류 전파 및 처리 메커니즘이 있는가?

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{
    "개별_워크플로우_완성도": {"소계": <0-6>, "평가": "<평가>"},
    "워크플로우_간_연결성_및_통합성": {"소계": <0-6>, "평가": "<평가>"},
    "분기_예외_처리": {"소계": <0-3>, "평가": "<평가>"},
    "총점": <0-15>,
    "종합_평가": "<전체적인 평가 요약>"
}
"""

MULTI_WORKFLOW_UPSTAGE_CRITERIA = """
# 다중 워크플로우 업스테이지 제품 활용도 심사 기준 (15점)

⚠️ **중요: 엄격한 평가 원칙**
- 점수는 매우 엄격하게 부여하십시오.
- **중요**: 모든 워크플로우에서 업스테이지 기술을 활용할 필요는 없습니다.
- 프로젝트 전체에서 업스테이지 기술이 적절히 활용되었는지 평가하세요.

## 평가 핵심 질문
1. 프로젝트 전체에서 업스테이지 API가 적절히 사용되었는가?
2. 각 워크플로우의 목적에 맞는 API가 선택되었는가?
3. 업스테이지 기술이 필요한 부분에만 사용되었는가? (과도한 사용은 감점)

## 평가 항목:

### 2-1. API 사용 적합성 (5점)
**핵심 평가 포인트:**
- 프로젝트 전체에서 업스테이지 API가 공식 엔드포인트로 사용되었는가?
- 각 워크플로우의 목적에 맞는 API가 선택되었는가?
- Credential이 안전하게 관리되었는가?

**중요**: 
- 모든 워크플로우에서 업스테이지 API를 사용할 필요는 없습니다.
- 업스테이지 기술이 필요한 부분에만 적절히 사용되었는지 평가하세요.
- 예: 문서 파싱이 필요한 워크플로우에서만 Document Parse API 사용

### 2-2. Prompt / System 설계 (5점)
- 업스테이지 API를 사용하는 워크플로우에서 명확한 역할(system message)이 정의되었는가?
- JSON/schema 강제력이 있는가?
- 프롬프트가 깔끔하고 구조화되어 있는가?

### 2-3. 기능 조합·오케스트레이션 (5점)
- 여러 워크플로우에서 업스테이지 API를 사용하는 경우, 단계적 파이프라인으로 구성되었는가?
- 전/후처리가 적절한가?
- 중복 호출이 없는가?

**중요**: 
- 업스테이지 API를 사용하지 않는 워크플로우가 있어도 감점하지 마세요.
- 프로젝트 전체에서 업스테이지 기술이 필요한 부분에 적절히 활용되었는지 평가하세요.

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{
    "API_사용_적합성": {"소계": <0-5>, "평가": "<평가>"},
    "Prompt_System_설계": {"소계": <0-5>, "평가": "<평가>"},
    "기능_조합_오케스트레이션": {"소계": <0-5>, "평가": "<평가>"},
    "총점": <0-15>,
    "종합_평가": "<전체적인 평가 요약>"
}
"""

# =============================================================================
# 1. 기술적 완성도 심사 기준 (15점)
# =============================================================================

TECHNICAL_CRITERIA = """
# 기술적 완성도 심사 기준 (15점)

⚠️ **중요: 엄격한 평가 원칙**
- 점수는 매우 엄격하게 부여하십시오. 완벽하지 않으면 감점하십시오.
- "거의 완성" 또는 "대부분 좋음"은 충분하지 않습니다. 기준을 정확히 충족해야만 점수를 부여하십시오.
- 불확실하거나 명확하지 않은 경우는 낮은 점수를 부여하십시오.
- 기준을 완전히 충족하지 않으면 해당 항목에 대한 점수를 부여하지 마십시오.

워크플로우 JSON 파일을 분석하여 다음 기준으로 평가하십시오.

## LLM이 볼 수 있는 것 (JSON 구조만으로 판단 가능)

- 노드 구조 & 연결 관계 (`nodes`, `connections`)
- 어떤 트리거에서 시작하는지 (예: ChatTrigger, Webhook 등)
- 브랜치/분기 설계 (IF, Switch, Merge 노드 등)
- 예외 처리/에러 처리 패턴이 있는지
- HTTP 요청 노드에서:
  - 어떤 API를 호출하는지 (URL, `api.upstage.ai`, `model: solar-pro2` 등)
  - 요청/응답을 어떻게 후처리하는지 (Code 노드, Set 노드)
- Code 노드의 JS 로직 수준 (데이터 머지, 키 관리, 예외 처리 등)
- "TODO", "DEACTIVATED", "수정할 것" 같은 미완성 시그널
- intent 분류 → Switch → 각 intent별 분기 구조가 "닫혀 있는지"
- 최종 액션까지 도달하는지 (예: 이메일 발송, DB 저장 등)

## 평가 항목:

### 1-1. 구조 완결성 & 모듈화 (5점)

**핵심 평가 포인트:**
- Trigger→Output까지 경로 완성, dead node 없음
- 역할 기반 네이밍·모듈화

#### 전체 경로 완성도 & Dead 노드 없음 (3점)
- 최소 1개의 **trigger node** 존재 (`type`: `webhook`, `scheduleTrigger`, `chatTrigger` 등)
- trigger → intermediate nodes → output nodes로 이어지는 **단절 없는 경로** 존재
- 어떤 노드도 **incoming/outgoing connection 둘 다 없음**이면 감점
- output 노드는 이메일, 파일 업로드, DB, webhook 응답 등 **최종 목적 기능을 갖는 노드**

#### 역할 기반 네이밍 & 모듈화 (2점)
- 노드명이 "HTTP Request", "Code" 같은 기본명이 아닌 **기능 중심 명명** (예: "Upstage DP 호출", "요약 후처리")
- 반복 로직은 loop / batch 노드로 모듈화
- 공통 전처리는 별도 노드화 (분산 X)

### 1-2. 데이터·스키마 일관성 (5점)

**핵심 평가 포인트:**
- key 일관성(`text/data/json`)
- 불필요한 overwrite 없음
- merge 정합성, output 필드 보존

#### key 일관성 (2점)
- HTTP 노드 응답 필드: `response.data` 또는 `body.choices[0].message.content`
- Code/Set 노드에서 output key 일관성: 다음 노드에서 참조하는 key와 일치
- `{{ $json.XXX }}` 표현식에서 key 오타/불일치 없음

#### 불필요한 overwrite 없음 & output 필드 보존 (2점)
- Set 노드로 "동일한 key를 여러 번" overwrite하지 않음
- "이전 단계 결과를 보존"하면서 새 필드를 추가하는 패턴
- 최종 노드까지 "필요한 필드"가 유지됨

#### Merge 노드 정합성 (1점)
- Merge 노드에서 key collision 처리 명확 (`mode: "merge"`, `"append"`, `"chooseBranch"` 등)
- 병합 후 schema가 다음 노드 입력과 호환

### 1-3. 분기/예외 처리 (5점)

**핵심 평가 포인트:**
- 의미 있는 조건 분기
- fallback/default 경로 존재

#### 의미 있는 조건 분기 (3점)
- IF / Switch 노드에서 조건 로직 명확 (예: `intent === "질문"` / `response.status === 200`)
- 분기 후 각 경로가 **의미 있는 차이**를 갖는 처리로 이어짐

#### Fallback / Default 경로 존재 (2점)
- Switch 노드에 `default` 케이스 존재
- IF 노드의 false 경로에도 최소한의 처리 또는 명시적 "무응답" 노드
- 예외 발생 시 **최소한의 사용자 응답 반환**

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{
    "구조_완결성_및_모듈화": {
        "전체_경로_완성도_및_dead노드_없음": <0-3>,
        "역할기반_네이밍_모듈화": <0-2>,
        "소계": <0-5>,
        "평가": "<구조 완결성 및 모듈화 전체에 대한 구체적 평가>"
    },
    "데이터_스키마_일관성": {
        "key_일관성": <0-2>,
        "불필요한_overwrite_없음_및_output필드_보존": <0-2>,
        "merge_노드_정합성": <0-1>,
        "소계": <0-5>,
        "평가": "<데이터 스키마 일관성 전체에 대한 구체적 평가>"
    },
    "분기_예외_처리": {
        "의미있는_조건_분기": <0-3>,
        "fallback_default_경로": <0-2>,
        "소계": <0-5>,
        "평가": "<분기/예외 처리 전체에 대한 구체적 평가>"
    },
    "총점": <0-15>,
    "종합_평가": "<전체적인 평가 요약>"
}
"""

# =============================================================================
# 2. 업스테이지 제품 활용도 심사 기준 (15점)
# =============================================================================

UPSTAGE_CRITERIA = """
# 업스테이지 제품 활용도 심사 기준 (15점)

⚠️ **중요: 엄격한 평가 원칙**
- 점수는 매우 엄격하게 부여하십시오. 완벽하지 않으면 감점하십시오.
- "거의 완성" 또는 "대부분 좋음"은 충분하지 않습니다. 기준을 정확히 충족해야만 점수를 부여하십시오.
- 불확실하거나 명확하지 않은 경우는 낮은 점수를 부여하십시오.
- 기준을 완전히 충족하지 않으면 해당 항목에 대한 점수를 부여하지 마십시오.

워크플로우 JSON 파일을 분석하여 업스테이지 제품 활용도를 평가하십시오.

## 평가 항목:

### 2-1. API 사용 적합성 (5점)

**핵심 평가 포인트:**
- 공식 엔드포인트 사용
- credential 보안
- 목적 적합 API 선택

#### 공식 엔드포인트 사용 (2점)
- `https://api.upstage.ai/v1/solar/...` 또는 공식 문서 명시 경로
- `/chat/completions`, `/document-ai/...` 등 **공식 API 스펙에 맞는 경로**
- custom endpoint / deprecated path 사용하면 감점

#### Credential 보안 (1점)
- API Key를 코드에 하드코딩하지 않음 (`{{ $credentials.upstageApi.apiKey }}` 등 credential 참조)
- Authorization 헤더 형식 정확: `Bearer {{API_KEY}}`

#### 목적 적합 API 선택 (2점)
- **문서 파싱** → Document Parse
- **임베딩/검색** → Embeddings API
- **대화/생성** → Solar Chat
- **이미지 추출** → Layout Analysis
- 목적-API 매칭이 적절한지 평가
- 예: "OCR이 필요한데 Chat API만 쓴" 경우 감점

### 2-2. Prompt / System 설계 (5점)

**핵심 평가 포인트:**
- 명확한 역할(system)
- JSON/schema 강제력
- 깔끔한 프롬프트

#### 명확한 역할 (system message) (2점)
- `messages[0].role === "system"`에 역할/제약/출력 형식 정의
- 예: "너는 회의록 작성 전문가입니다. 아래 형식으로만 출력하십시오."
- system message 없으면 감점

#### JSON / schema 강제력 (2점)
- `response_format: { type: "json_object" }` 또는 prompt에 "JSON만 출력" 명시
- Structured Output 사용 시 `schema` 필드 정의 여부
- 예: 의도 분류, 필드 추출 시 "반드시 {intent: ..., entities: ...} 형식" 지시

#### 깔끔한 프롬프트 (불필요 반복 X) (1점)
- 동일 지시 중복 없음 (예: "JSON으로 출력하세요"를 system/user 양쪽에 반복 X)
- 프롬프트가 "명확·간결·구조화"되어 있음
- Few-shot 예시가 있다면 일관된 형식

### 2-3. 기능 조합·오케스트레이션 (5점)

**핵심 평가 포인트:**
- DP→IE→Solar 등 단계적 파이프라인
- 전/후처리 적절
- 중복 호출 없음

#### 단계적 파이프라인 (2점)
- 문서 업로드 → DP로 파싱 → 텍스트 추출 → Solar Chat으로 요약/분석 같은 **논리적 흐름**
- 각 단계 output이 다음 단계 input으로 자연스럽게 전달
- 예: DP 결과 `text`를 Chat API `user` 메시지에 삽입

#### 전/후처리 적절 (2점)
- API 호출 전: 텍스트 정제, 필드 매핑, validation (Code/Set 노드)
- API 호출 후: JSON 파싱, 필요 필드 추출, 에러 핸들링
- 예: Chat 응답에서 `choices[0].message.content`를 추출 → JSON 파싱 → 다음 단계 전달

#### 중복 호출 없음 (1점)
- 동일 입력에 대해 같은 API를 여러 번 호출하지 않음
- 불필요한 "loop 내 반복 API 호출" X
- batch 처리 또는 1회 concatenate 후 호출 같은 최적화 시도 시 가점

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{
    "API_사용_적합성": {
        "공식_엔드포인트_사용": <0-2>,
        "credential_보안": <0-1>,
        "목적_적합_API_선택": <0-2>,
        "사용된_API_목록": ["<API1>", "<API2>"],
        "소계": <0-5>,
        "평가": "<API 사용 적합성 전체에 대한 구체적 평가>"
    },
    "Prompt_System_설계": {
        "명확한_역할_system_message": <0-2>,
        "JSON_schema_강제력": <0-2>,
        "깔끔한_프롬프트": <0-1>,
        "소계": <0-5>,
        "평가": "<Prompt/System 설계 전체에 대한 구체적 평가>"
    },
    "기능_조합_오케스트레이션": {
        "단계적_파이프라인": <0-2>,
        "전후처리_적절": <0-2>,
        "중복_호출_없음": <0-1>,
        "소계": <0-5>,
        "평가": "<기능 조합/오케스트레이션 전체에 대한 구체적 평가>"
    },
    "총점": <0-15>,
    "종합_평가": "<전체적인 평가 요약>"
}
"""

# =============================================================================
# 3. 실용성 심사 기준 (30점)
# =============================================================================

PRACTICALITY_CRITERIA = """
# 실용성 심사 기준 (30점)

⚠️ **중요: 엄격한 평가 원칙**
- 점수는 매우 엄격하게 부여하십시오. 완벽하지 않으면 감점하십시오.
- "거의 완성" 또는 "대부분 좋음"은 충분하지 않습니다. 기준을 정확히 충족해야만 점수를 부여하십시오.
- 불확실하거나 명확하지 않은 경우는 낮은 점수를 부여하십시오.
- 기준을 완전히 충족하지 않으면 해당 항목에 대한 점수를 부여하지 마십시오.

제출된 프로젝트 설명을 분석하여 다음 기준으로 평가하십시오.

## 평가 항목:

### 3-1. 실제 업무 적용 가능성 (10점)

**핵심 평가 포인트:**
- 반복 업무 제거
- 실제 사용 시나리오 선명
- 시간 절감 효과 명확

**핵심 질문:**
- 이 워크플로우는 실제로 **사람이 하던 수작업을 얼마나 줄이는가?**
- "언제/누가/무엇을" 줄일 수 있는지 명확한가?
- 자동화의 **시간 절감·오류 감소** 효과가 분명한가?

#### 반복 업무 제거 (3점)
- "매일/매주 반복되는 작업"을 자동화하는지 명확
- 예: 일일 리포트 생성, 문의 자동 분류, 정기 데이터 집계 등
- **단발성 작업이 아닌, 지속 사용 가능**

#### 실제 사용 시나리오 선명 (4점)
- "누가 / 언제 / 어떻게 사용하는지" 구체적 서술
- 예: "고객센터 직원이 문의 접수 시 즉시 실행", "마케팅 팀이 주간 보고서 작성 시 활용"
- 사용 flow가 명확 (trigger 조건, input 출처, output 활용처)

#### 시간 절감 효과 명확 (3점)
- "Before (수동 작업 N시간) → After (자동화 M분)" 같은 **정량적 효과** 제시
- 또는 "오류율 감소 / 일관성 향상" 등 **질적 개선** 명시
- 효과가 체감 가능한 수준

### 3-2. 자동화 효과 및 사용자 편의성 (10점)

**핵심 평가 포인트:**
- 자동화 효과 및 학습 편의성
- 재사용 또는 일반화 가능한 구조

**핵심 질문:**
- "이 자동화 구조가 다른 사람·다른 조직·다른 데이터에서도 재사용 가능한가?"
- "특정 상황에만 동작하는 해킹 같은 구조가 아닌가?"
- "입력 구조·추상화·구성 요소가 확장성을 고려하는가?"

#### 재사용·일반화 가능성 (5점)
- 특정 회사/팀에만 종속된 하드코딩 최소화
- 예: "우리 회사 특정 DB 스키마에만 동작" → 낮은 점수
- 입력 포맷만 맞추면 다른 곳에서도 바로 사용 가능 → 높은 점수
- workflow가 **일반화된 구조** (예: 파일 업로드 → 파싱 → 분석 → 출력)

#### 자동화 효과 및 학습 편의성 (5점)
- 자동화가 실제로 시간을 절약하거나 효율을 높이는가?
- 사용자가 쉽게 이해하고 사용할 수 있는 구조인가?
- 학습 흐름을 방해하지 않고 자연스럽게 보조하는 기능인가?

### 3-3. 사용자 편의성 (10점)

**핵심 평가 포인트:**
- 최종 사용자 입장에서 직관적으로 쓸 수 있는가?

**핵심 질문:**
- "기술 지식이 없는 사용자도 쉽게 사용할 수 있는가?"
- "입력이 간단하고 출력이 명확한가?"
- "에러 발생 시 사용자가 이해할 수 있는 메시지가 제공되는가?"

#### 직관적인 입력 방식 (4점)
- 사용자가 제공해야 하는 입력이 명확하고 간단
- 예: "파일 업로드만 하면 됨", "간단한 질문 입력"
- 복잡한 설정이나 기술 지식 불필요

#### 명확한 출력 및 피드백 (3점)
- 결과물이 사용자가 이해하기 쉬운 형태로 제공
- 예: "요약된 텍스트", "분류 결과와 신뢰도", "구조화된 데이터"
- 진행 상황이나 완료 알림 제공

#### 에러 처리 및 가이드 (3점)
- 에러 발생 시 사용자 친화적인 메시지 제공
- 예: "파일 형식이 올바르지 않습니다. PDF 또는 DOCX를 업로드해주세요"
- 사용 방법에 대한 간단한 가이드나 예시 제공

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{
    "실제_업무_적용_가능성": {
        "반복_업무_제거": <0-3>,
        "실제_사용_시나리오_선명": <0-4>,
        "시간_절감_효과_명확": <0-3>,
        "소계": <0-10>,
        "평가": "<실제 업무 적용 가능성 전체에 대한 구체적 평가>"
    },
    "자동화_효과_및_사용자_편의성": {
        "재사용_일반화_가능성": <0-5>,
        "자동화_효과_및_학습_편의성": <0-5>,
        "소계": <0-10>,
        "평가": "<자동화 효과 및 사용자 편의성 전체에 대한 구체적 평가>"
    },
    "사용자_편의성": {
        "직관적인_입력_방식": <0-4>,
        "명확한_출력_및_피드백": <0-3>,
        "에러_처리_및_가이드": <0-3>,
        "소계": <0-10>,
        "평가": "<사용자 편의성 전체에 대한 구체적 평가>"
    },
    "총점": <0-30>,
    "종합_평가": "<전체적인 평가 요약>"
}
"""

# =============================================================================
# 4. 문제 해결 접근법 심사 기준 (30점)
# =============================================================================

PROBLEM_SOLVING_CRITERIA = """
# 창의성 / 문제 해결 접근법 심사 기준 (20점)

⚠️ **중요: 엄격한 평가 원칙**
- 점수는 매우 엄격하게 부여하십시오. 완벽하지 않으면 감점하십시오.
- "거의 완성" 또는 "대부분 좋음"은 충분하지 않습니다. 기준을 정확히 충족해야만 점수를 부여하십시오.
- 불확실하거나 명확하지 않은 경우는 낮은 점수를 부여하십시오.
- 기준을 완전히 충족하지 않으면 해당 항목에 대한 점수를 부여하지 마십시오.

제출된 프로젝트 설명을 분석하여 다음 기준으로 평가하십시오.

## 평가 항목:

### 4-1. 문제 정의의 독창성 (10점)

**핵심 평가 포인트:**
- 자동화 대상 선정이 새롭거나, 실질적 문제를 잘 포착했는가?

**핵심 질문:**
- "이 문제는 실제 사용자·조직이 겪는 '진짜 문제'인가?"
- "문제의 정의가 실제 상황과 맞아떨어지는가?"
- "문제 정의의 방식이나 관점에서 독창성이 있는가?"

#### 실질적 문제 포착 (5점)
- "~가 불편하다 / 시간이 오래 걸린다 / 실수가 잦다" 같은 **구체적 문제 상황** 제시
- 추상적("효율 향상") 아닌, 측정 가능한 문제 (예: "하루 2시간 소요", "오류율 30%")
- 문제 정의가 명확하고 공감 가능
- 실제 사용자의 pain point를 정확히 파악

#### 차별화된 관점 및 독창성 (5점)
- 단순 "이런 기능 있으면 좋겠다"가 아닌, **왜 지금 방식이 한계인지 분석**
- 경쟁 서비스/기존 방법 대비 차별점 제시
- 데이터나 사례 기반 근거 (예: "현재 수기 작업 시 20분 소요, 자동화 시 2분 예상")
- 문제를 바라보는 새로운 시각이나 접근 방식

### 4-2. 솔루션 구성의 참신함 (10점)

**핵심 평가 포인트:**
- 기존 방법과 차별화된 접근을 했는가?
- 제한된 노드/도구 내에서 창의적 해결을 시도했는가?

**핵심 질문:**
- "단순히 API를 묶어놓은 구조인가?"
- "문제를 어떤 방식으로 바라보고 해결하려 했는지 독창성이 있는가?"
- "기술 구성의 조합이나 시각이 새롭고 설득력이 있는가?"

#### 차별화된 접근 (5점)
- "DP 호출 + Chat 호출"만으로 끝나는 게 아닌, **전략적 조합**
- 예: ① 문서 파싱 → ② 키워드 추출 → ③ 외부 DB 검색 → ④ 최종 보고서 생성 같은 **다단계 로직**
- 또는 "조건 분기 + 반복 + 병합" 같은 **복잡도 있는 구조**
- 각 단계가 논리적으로 연결되고 필요성이 명확

#### 창의적 해결 (5점)
- 기존 템플릿/예제를 그대로 가져온 게 아닌, **문제 해결에 특화된 설계**
- 예: "intent 분류 후 각 intent별 맞춤 프롬프트" / "문서 타입별 다른 파싱 전략" 등
- 창의적 아이디어나 독특한 workflow 패턴 (예: 피드백 루프, 다중 에이전트 시뮬레이션 등)
- 제한된 도구 내에서 창의적 해결을 시도했는가?

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{
    "문제_정의의_독창성": {
        "실질적_문제_포착": <0-5>,
        "차별화된_관점_및_독창성": <0-5>,
        "소계": <0-10>,
        "평가": "<문제 정의의 독창성 전체에 대한 구체적 평가>"
    },
    "솔루션_구성의_참신함": {
        "차별화된_접근": <0-5>,
        "창의적_해결": <0-5>,
        "소계": <0-10>,
        "평가": "<솔루션 구성의 참신함 전체에 대한 구체적 평가>"
    },
    "총점": <0-20>,
    "종합_평가": "<전체적인 평가 요약>"
}
"""

# =============================================================================
# 평가 재검토 기준
# =============================================================================

REVIEW_CRITERIA = """
# 평가 재검토 기준

다음 평가 결과를 재검토하고, 점수가 적절한지 확인하십시오.

## 원본 데이터:
{data}

## 심사 기준:
{criteria}

## 초기 평가 결과:
{initial_score}

## 재검토 요청사항:
⚠️ **중요: 엄격한 재검토 원칙**
- 초기 평가가 너무 후했다면 반드시 점수를 낮추십시오.
- "거의 완성" 또는 "대부분 좋음"은 충분하지 않습니다. 기준을 완전히 충족해야만 점수를 부여하십시오.
- 불확실하거나 명확하지 않은 경우는 보수적으로 낮은 점수를 유지하거나 더 낮추십시오.

1. 점수가 심사 기준에 부합하는가? (너무 후하지 않은가?)
2. 평가가 너무 관대하지 않은가? (엄격하게 평가되었는가?)
3. 모든 항목이 공정하고 엄격하게 평가되었는가?
4. 평가 근거가 충분히 구체적인가?
5. 세부 항목 점수의 합계가 소계/총점과 일치하는가?
6. 초기 평가가 너무 후했다면 반드시 점수를 낮추었는가?

## 출력 형식:
JSON 형식으로 다음과 같이 출력하십시오:
{{
    "재검토_결과": "<유지|수정>",
    "수정_필요_이유": "<수정이 필요한 경우, 그 이유>",
    "최종_점수": {{
        ... (원본과 동일한 형식의 점수 객체, 필요시 수정된 점수)
    }},
    "재검토_의견": "<재검토 의견>"
}}
"""