Domain Knowledge Builder — 도메인 지식 베이스 생성기
N편의 논문 + 도메인 이름 → 질의 가능한 A등급 도메인 지식 베이스 스킬을 생성합니다. 지식 베이스 구조: DAG (5가지 노드 유형 + 10가지 관계) + 멘탈 모델 + 질의 프로토콜 + 정직한 경계. 품질 관문: darwin 2.0의 9차원 점수, ≥B+ (80) 이상이어야 생성 성공.
핵심 멘탈 모델
1. 지식 ≠ 정의의 단순 나열
사용 가능한 도메인 지식 베이스는 정의/정리를 단순히 옮겨 놓는 것이 아니라, 해당 도메인이 세상을 보는 렌즈(멘탈 모델)를 정제하고, 지식 노드로 그 렌즈를 뒷받침하는 것입니다. "내 데이터 흐름이 비가환인데, CP가 나를 어떻게 도와줄까?"라는 질문에 순수 정의 나열로는 답할 수 없지만, 멘탈 모델 기반 지식 베이스는 입장을 추론할 수 있습니다. 따라서 수집(ingest) 프로세스에는 노드 추출만이 아닌 멘탈 모델 정제 단계(S5)가 반드시 포함되어야 합니다.
2. Karpathy 생애 주기 × DAG 구조
- Karpathy LLM Wiki의「생애 주기」: raw(불변 원천) → wiki(LLM 유지) → SCHEMA(규범)의 3계층 + 수집(Ingest)/질의(Query)/린트(Lint)의 3가지 워크플로우. 지식 베이스는 한 번 추출된 스냅샷이 아니라 성장하는 유기체입니다.
- DAG의「구조」: 노드 간 관계는 단순 분류가 아닌
guarantees/generalizes/contradicts/depends_on과 같은 관계를 포함합니다. 정리 A가 정리 B를 도출하고, 방법 C가 방법 D와 모순되는 이러한 관계는 도메인 지식의 핵심이며, 평면적인 디렉토리 구조로는 담을 수 없습니다. - 융합: Karpathy는 "지식이 어떻게 성장하는지"(생애 주기)를, DAG는 "지식이 어떻게 연결되는지"(구조)를 관리합니다.
3. 생성기는 제어 가능해야 함 (D7)
메타 스킬이 일반 스킬과 다른 본질은 다른 스킬을 생성한다는 점입니다. 이는 대량의 파일 시스템 쓰기, 하위 에이전트 생성, 네트워크 사용을 수반합니다. 이는 반드시 제어 가능해야 합니다: 모든 수집은 체크포인트로 복구 가능해야 하고, darwin 평가를 통과하지 못하면 git revert가 가능해야 하며, 모든 노드는 출처(provenance)를 추적 가능해야 하고, 같은 논문을 다시 실행하면 동일한 노드 ID를 생성해야 합니다(결정론). 그렇지 않으면 6개월 후 유지보수가 불가능합니다. 이 네 가지 기둥(롤백 가능/감사 가능/결정론/사전 점검)은 생성기 스킬의 표준 준수 조건입니다(darwin 9차원의 generator 하위 클래스).
사용 시기 / 사용하지 말아야 할 시기
사용:
- "전문가가 'X를 어떻게 보는지' + '그 이유(근거)'에 답변할 수 있는 컨설턴트 스킬을 만들어 주세요."
- "전문가의 논문/인터뷰/블로그를 멘탈 + 지식 이중 엔진으로 변환해 주세요."
- "이 몇 편의 논문을 질의 가능한 지식 베이스로 만들어 주세요."
- "X 도메인에 대한 DAG 지식 베이스를 구축해 주세요."
- "N개의 PDF가 있는데, 입장을 추론할 수 있는 도메인 도우미를 원합니다."
라우팅 구분:
- 순수 도메인 지식 베이스(전문가 관점 불필요) → DKB 원래 모드 (
examples/conformal-prediction) - 전문가 관점(전문가 판단 + 근거 필요) → 본 확장 모드 (expert-advisor 모드)
사용하지 않음(다른 스킬로 라우팅):
- "Split CP가 뭐야?" → 기존 CP 지식 베이스 조회 (
examples/conformal-prediction) - "이 책 요약해 줘" → book-to-skill로 단일 책 스킬 직접 생성
- "한 사람의 사고 방식을 증류해 줘(도메인 지식 불필요)" → nuwa-skill 사용
아키텍처 (5계층)
domain-knowledge-skill/
├── SKILL.md # 본 파일 (메타 스킬 진입점)
├── schema/schema.md # 지식 규범 (5가지 유형 + 10가지 관계 + D7 제어 가능성)
├── pipeline/ # 수집(Ingest)/질의(Query)/린트(Lint) 워크플로우
│ ├── ingest.md # 7단계 파이프라인 계약 (S1-S7)
│ ├── query.md # 5단계 DAG 탐색 질의
│ ├── lint.md # 구조 + 생성기 규정 준수 검사
│ ├── run-dag-pipeline.js # 워크플로우 오케스트레이션 스크립트
│ └── state/ # D7 런타임
│ ├── init_run.py # UUID + git + run-manifest + preflight
│ └── lint_d7.py # 네 기둥 린트
├── engines/ # 재사용 엔진
│ ├── book_to_skill/ # virgiliojr94 추출 엔진 (technical 모드)
│ ├── darwin-rubric.md # 9차원 품질 점수 (9차원 하위 클래스 두 가지)
│ └── nuwa-validation.md # 도메인화된 삼중 검증
├── references/ # 템플릿 (계획 중)
└── examples/
└── conformal-prediction/ # 황금 참조 (88점 A-, 지연 로딩)
7단계 수집 파이프라인 (D3 단계적 분할)
결정론 (워크플로우 팬아웃) 상호작용/판단 (하위 에이전트 체인)
───────────────────── ─────────────────────
S1 추출 ──┬──▶ S2×N 병렬 ──┐
└──▶ ... ├──▶ S3 병합 ──▶ S4 탐색 ──▶ S5 멘탈 모델 ──▶ S6 검증 ──▶ S7 조립 ──▶ darwin 관문
│ (contradicts (병렬 3) (삼중 검증) (신규) (<4K) (≥B+)
│ 수동 확인)
상세 계약은 pipeline/ingest.md 참조. 핵심 제약:
- S1은 docling preflight 필수 (schema §12.4, technical 모드 하드 의존성)
- S2 노드 ID는
<type>-<source>-<canonical-term>형식 준수 (schema §10 Determinism) - S3에서
contradicts/does_not_guarantee간선 발생 시contact_supervisor로 수동 확인 필수 - S5는
engines/nuwa-validation.md를 로드하여 삼중 검증 수행 - S6/S7은 fresh-context 하위 에이전트 사용 (독립 검증/점수, 자기 평가 금지)
- 전체 과정의 모든 노드에 출처(provenance) 기록 (generated_by_step/run_id/source_span)
품질 관문 (darwin 2.0, 9차원)
engines/darwin-rubric.md를 로드하여 fresh-context 하위 에이전트가 점수 평가:
| 차원 | 가중치 | 핵심 포인트 |
|---|---|---|
| ①구조적 완전성 ②명확성 ③내용 완전성 ④실행 가능성 | 15%×4 | frontmatter/워크플로우/커버리지/실행 가능 |
| ⑤정확성 ⑥일관성 | 10%×2 | 정리 원문 정확/단절된 참조 없음 |
| ⑦실행 효율성 ⑧견고성 | 8%/7% | 토큰 예산/정직한 경계 |
| ⑨메타 스킬 규정 준수 | 5% | generator-skill 하위 클래스: 네 기둥 |
9차원 하위 클래스 두 가지(oracle 통찰): query-skill (CP형, 읽기 전용) vs generator-skill (본 스킬형, 제어된 쓰기 허용 but 네 기둥 충족 필수: 롤백 가능/감사 가능/결정론/사전 점검). 이를 통해 생성기가 공정하게 품질 관문을 통과할 수 있습니다.
래칫 메커니즘: darwin <B+ → 마지막 단계 git revert → 낮은 점수 차원 진단 → 수정 후 재평가. 연속 3회 개선 없음 → 탐색적 재작성 제안.
5개 참조 소스의 활용 방향
| 소스 | 활용 방향 | 재사용 방식 |
|---|---|---|
| Karpathy LLM Wiki | schema/ + pipeline/ | 깔끔한 상속: 3계층 아키텍처 + 수집(Ingest)/질의(Query)/린트(Lint) 생애 주기 |
| book-to-skill | engines/book_to_skill/ | 깔끔한 vendor: 추출 엔진 (technical 모드 수식 보존) |
| nuwa-skill | engines/nuwa-validation.md | 방법론 정제: 삼중 검증 (expression DNA 제거) |
| darwin-skill | engines/darwin-rubric.md | 이중 소스 재구성: validation-report의 9차원 + 구버전 8차원 대조 |
| dag-executor | 철학 참고만 | wave 기반 병렬 + 파일 잠금 (구현은 pi 워크플로우/subagent 사용) |
examples/conformal-prediction (황금 참조)
지연 로딩 — 기본 스킬 라우팅에 참여하지 않으며, 명시적 요청 시 활성화:
- v1.1.0 / 50개 노드 / 138개 간선 / 0개 단절 / darwin 88점 (A-)
- 3개 출처 (Angelopoulos 2022 / Teneggi 2025 / Min 2026)
- 용도: (1) 새 도메인 수집 시 품질 기준; (2) 사용자가 "공형 예측"을 명시적으로 조회할 때 로드
제약 사항과 정직한 경계
하드 제약:
- docling은 technical 모드 하드 의존성 (학술 논문에서 수식이 빠지면 가치 없음, 희생 불가)
- SKILL.md 본문 <4K 토큰 (압축 시末尾부터 잘라냄)
- 모든 노드 출처(provenance) 필수 (새 수집)
- 생성된 스킬 경로는 스킬 루트 기준 상대 경로만 사용 (링크 단절 방지)
할 수 없는 것:
- 직관을 증류할 수 없음 — 프레임워크는 추출할 수 있지만, 영감은 추출 불가
- 도메인의 모든 논문을 커버할 수 없음 — 사용자가 제공한 소스만 커버
- 소스 품질을 자동으로 판단할 수 없음 — 쓰레기 입력 = 쓰레기 출력 (저품질 논문 → 저품질 지식 베이스)
- 전문가 판단을 대체할 수 없음 — contradicts 간선은 반드시 수동 확인 필요
알려진 한계:
- docling 버전 변경 시 추출 품질이 조용히 저하될 수 있음 (테스트로 포착 불가)
- canonical-term의 LLM 추출은 완전 결정론적이지 않음 (같은 논문을 두 번 추출하면 해시가 다를 수 있으며, Lint가 보고)
- 큰 논문(>50K 토큰) 추출 비용이 높음 (분할 수집 권장)
빠른 시작
사용자: diffusion-models 도메인 지식 베이스를 만들어 주세요. 논문은 ~/papers/ddpm.pdf, ~/papers/score-sde.pdf에 있습니다.
→ 본 스킬:
1. 도메인 + 소스 확인 + docling 사전 점검
2. 7단계 파이프라인 실행 (pipeline/ingest.md)
3. darwin 점수 평가, ≥B+이면 생성된 스킬을 ~/.pi/agent/skills/diffusion-models/로 전달
4. 사용자는 생성된 스킬을 추후 질의 가능
자세한 내용은 pipeline/ingest.md의 전체 계약을 참조하세요.
본 메타 스킬 버전: v0.1 | 5개 소스 재사용 + D7 제어 가능성 + darwin 2.0 품질 관문 | 황금 참조: examples/conformal-prediction (88/A-)