단발성 코딩 질문을 주제로 활용해, Persona · Intent · Quality Tier가 명시된 4턴(8 Message) 코딩 대화 데이터로 확장하는 LLM Data Augmentation Pipeline입니다.
단순히 LLM으로 대화를 생성하는 것에서 끝내지 않고, 별도의 Judge Model과 Rubric을 통해 각 Turn의 Intent와 품질을 검증하고 기준에 미달하면 해당 Turn을 다시 생성하도록 구성했습니다.
Generator: Gemini 2.5 Flash
Judge: Gemini 2.5 Pro
Orchestration: LangGraph
Output: ShareGPT-style JSONL
코딩 LLM을 위한 대화 데이터는 단발성 질문뿐 아니라 실제 개발 과정처럼 여러 Turn에 걸쳐 맥락이 변화하는 데이터가 필요합니다.
예를 들어 하나의 개발 대화에서도 다음과 같은 상호작용이 이어질 수 있습니다.
- 개발 환경과 제약 조건 설정
- 새로운 기능 구현
- 기존 코드 수정
- 오류 디버깅
- 개념 탐색
- 이전 응답에 대한 후속 진행
하지만 단순한 LLM 생성만으로는 원하는 Intent가 제대로 표현되었는지, Persona에 맞는 질문인지, 목표한 품질 수준에 도달했는지 안정적으로 통제하기 어렵습니다.
이 프로젝트에서는 하나의 Seed Question을 주제(topic)로만 사용하고,
Seed → Persona / Intent Sequence → Conversation Generation → LLM Judge → Retry → Dataset
과정을 자동화했습니다.
flowchart LR
A[Seed Question] --> B[Seed Transformer]
B --> C[Persona + Intent + Quality Tier]
C --> D[Gemini Flash Generator]
D --> E[Turn Candidate]
E --> F[Gemini Pro Judge]
F -->|Pass| G{Next Turn?}
F -->|Fail| D
G -->|Yes| D
G -->|No| H[ShareGPT JSONL]
H --> I[Intent / Tier Metadata]
기본 그래프는 다음 순서로 동작합니다.
원본 코딩 질문에서 주제를 추출하고 첫 번째 Turn의 Target Intent에 맞는 사용자 발화로 재작성합니다.
Persona, 현재 Turn의 Intent, Target Quality Tier, 기존 대화 Context를 Generator에게 제공합니다.
Judge가 생성된 Turn이 Rubric과 Target Intent를 만족하는지 판정합니다.
Intent 또는 Quality 기준을 만족하지 못하면 해당 Turn만 다시 생성합니다.
모든 Turn이 통과하면 ShareGPT-style JSONL과 학습·분석용 Metadata를 함께 저장합니다.
현재 네 가지 개발자 Persona를 정의하고 있습니다.
| Persona | Turn 1 | Turn 2 | Turn 3 | Turn 4 |
|---|---|---|---|---|
strict_senior |
SETTING | CREATION | REFINEMENT | FOLLOW_UP |
curious_junior |
EXPLORATION | CREATION | DEBUGGING | FOLLOW_UP |
bug_fixer |
DEBUGGING | REFINEMENT | CREATION | FOLLOW_UP |
optimization_explorer |
EXPLORATION | REFINEMENT | CREATION | FOLLOW_UP |
Persona를 자기소개 문장으로 직접 표현하지 않고, 질문의 깊이·요구 수준·Context를 통해 드러내도록 설계했습니다.
SETTING— 개발 환경·역할·제약 조건 설정CREATION— 새로운 코드 또는 기능 요청REFINEMENT— 기존 코드·설계 수정 및 확장DEBUGGING— 오류·증상 기반 문제 해결EXPLORATION— 구현을 요구하지 않는 개념·비교 탐색FOLLOW_UP— 새로운 요구사항 없이 기존 흐름 계속 진행
세부 판정 기준은 Rubric.md에 정의되어 있습니다.
이 프로젝트에서는 생성과 평가를 하나의 모델 호출에 맡기지 않습니다.
- 코딩 대화 생성
- Persona 및 Intent 반영
- Target Quality Tier 반영
- 이전 Turn Context 유지
- 필요 시 Gold Reference / Few-shot 활용
생성 결과를 별도로 평가합니다.
Generated Turn
│
▼
Intent Validation
│
▼
Quality Tier Observation
│
├── Pass ──→ Next Turn
│
└── Fail ──→ Regenerate Current Turn
Judge의 출력은 자유 텍스트가 아니라 구조화된 Schema를 사용합니다.
{
"is_pass": true,
"reason": "...",
"quality_tier_observed": "high"
}최종 Routing은 pass / fail의 이진 판정을 사용하며, 파싱 또는 Schema 검증 실패 역시 기술적 실패로 처리하여 재시도합니다.
각 Turn에는 다음 중 하나의 목표 품질을 지정할 수 있습니다.
highmediumlow
예를 들어 다음과 같이 실행할 수 있습니다.
uv run python -m pipeline \
--tiers high,medium,low,high또는 미리 정의한 패턴을 사용할 수 있습니다.
all_high: [high, high, high, high]
all_medium: [medium, medium, medium, medium]
mixed_hhmm: [high, high, medium, medium]
mixed_hmlh: [high, medium, low, high]현재 Pipeline은 Target Tier와 Judge가 관측한 Tier를 비교하여 Turn의 수용 여부를 결정합니다.
pipeline_config.yaml에서 exact 또는 at_least 방식을 선택할 수 있으며, 현재 설정은 at_least입니다.
Generator와 Judge가 동일한 기준을 공유할 수 있도록 Intent별 Rubric을 명시했습니다.
예를 들어 DEBUGGING의 경우 사용자 발화에 다음 중 최소 하나가 있어야 합니다.
- Error Message
- Expected vs Actual
- Reproduction Clue
반면 단순히 "안 돼요"만 제시하는 경우 Target Intent를 충분히 충족하지 못한 것으로 판단합니다.
또한 공통적으로 다음을 검사합니다.
- 사용자 / Assistant 역할 유지
- 코드 블록 형식
- 메시지 길이
- Seed 언어 유지
- Persona와 기술 수준의 정합성
- Intent 간 혼합 여부
- 금지 콘텐츠
자세한 내용: Rubric.md
LLM 기반 생성과 평가는 동일한 조건에서도 결과가 달라질 수 있기 때문에, 같은 설정을 여러 번 실행해 결과 변동을 확인할 수 있도록 했습니다.
uv run python -m pipeline -n 5 \
--out output/repeated.jsonl--count / -n을 사용하면 동일한 Seed · Persona · Tier 설정으로 N회 실행합니다.
실제 반복 실행 과정에서도 Target Intent는 통과했지만 Judge가 관측한 Quality Tier가 달라져 실패하는 사례를 확인했고, 이를 바탕으로 Persona / Tier Rubric과 Retry 정책을 조정했습니다.
따라서 이 프로젝트에서는 생성 성공 여부뿐 아니라
- 어떤 기준에서 실패했는가
- 어떤 Turn에서 재생성이 발생했는가
- Target Tier와 Observed Tier가 어떻게 달랐는가
를 함께 기록합니다.
기본 산출물은 ShareGPT-style JSONL입니다.
{
"conversations": [
{
"from": "human",
"value": "..."
},
{
"from": "ai",
"value": "..."
}
],
"meta": {
"seed_id": "...",
"persona": "strict_senior",
"intent_sequence": [
"SETTING",
"CREATION",
"REFINEMENT",
"FOLLOW_UP"
],
"tier_sequence": [
"high",
"high",
"medium",
"medium"
],
"generator_model": "gemini-2.5-flash",
"judge_model": "gemini-2.5-pro"
}
}Metadata에는 Intent와 Quality Tier의 Gold Label을 함께 기록할 수 있어 생성 데이터의 분석 및 후속 학습에 활용할 수 있습니다.
- Python 3.12 권장
- Gemini API Key
uv권장
uv sync.env.example을 참고하여 .env를 생성합니다.
GEMINI_API_KEY=YOUR_API_KEYuv run python -m pipeline기본 출력:
output/smoke.jsonl
uv run python -m pipeline \
--persona bug_fixer \
--seed "리액트 훅으로 폼 검증 예시"uv run python -m pipeline -n 5자세한 CLI 및 설정 방법은 docs/EXECUTION.md를 참고합니다.
주요 설정은 pipeline_config.yaml에서 관리합니다.
pipeline_config.yaml
├── models
│ ├── generator
│ └── judge
├── conversation
├── intent_sequence
├── quality_tiers
├── gold_reference
├── routing
├── judge
├── output
└── monitoring
모델, Temperature, Turn 수, Persona별 Intent Sequence, Quality Tier, Retry 횟수 등을 코드 수정 없이 설정할 수 있도록 분리했습니다.
Data_Augmentation/
├── pipeline/
│ ├── graph.py
│ ├── smoke.py
│ ├── llm_utils.py
│ ├── prompt_build.py
│ └── ...
├── prompts/
├── schemas/
├── few_shots/
├── config/
├── docs/
│ ├── EXECUTION.md
│ ├── PROJECT_STATUS.md
│ └── QUALITY_TIER_POLICY.md
├── .maestro/
├── Rubric.md
├── few_shot_manifest.yaml
└── pipeline_config.yaml
- Python
- LangGraph
- LangChain
- Gemini 2.5 Flash
- Gemini 2.5 Pro
- Pydantic
- JSON Schema
- LangSmith
- uv
현재 구현 범위는 코딩 대화 데이터의 생성 및 Turn 단위 자동 검증입니다.
아직 다음 기능은 최종 구현 범위에 포함하지 않습니다.
- 대규모 Dataset 전체 자동 Batch 운영
- DPO Preference Pair 자동 생성
- Pairwise Judge 기반 Ranking
- 생성 데이터로 실제 모델을 Fine-tuning한 후의 Downstream 성능 비교
따라서 이 Repository는 완성된 대규모 Dataset 자체보다, LLM을 이용해 원하는 특성을 가진 Multi-turn 데이터를 생성하고 별도의 Judge와 Rubric으로 품질을 통제하는 Pipeline 설계에 초점을 둡니다.