# 연구 주제와 방법 안내

Canonical HTML: https://aogavrilov.com/ko/projects/

Document language: ko

관찰된 실패에서 출발해 그 실패에 맞는 진단, 제어 수단, 측정값, 근거 범위를 찾는다.

## 관찰한 문제에서 방법 선택하기

같은 표면 증상도 표현, 생성, 제어, 검증 단계에서 서로 다른 원인으로 나타날 수 있다.

| 관찰한 문제 | 첫 진단 | 필요한 근거 | 안내서 |
| --- | --- | --- | --- |
| 디코딩 출력 품질이 낮지만 어느 단계가 원인인지 모른다 | 원문, 재구성, 생성 출력을 같은 외부 평가기로 점수화한다. | 각 단계의 비교 가능한 분포와 꼬리 구간. | [단계별 병목 진단](https://aogavrilov.com/ko/projects/codec-bottleneck-diagnosis/#workflow) |
| 잠재 지표는 좋아졌지만 최종 품질은 그대로다 | 대리 지표의 개선이 디코딩 뒤에도 유지되는지 확인한다. | 짝지은 디코딩 출력과 최종 지표. | [대리 지표 전달 점검](https://aogavrilov.com/ko/projects/codec-bottleneck-diagnosis/#decision-table) |
| 코드 편집기가 요청 영역 밖까지 다시 쓴다 | 보호 경계를 명시하고 바깥 영역의 diff를 측정한다. | 국소성과 작업 성공을 함께 측정. | [국소 편집 평가](https://aogavrilov.com/ko/projects/discrete-latent-generation/#measurement) |
| 재생성이 문법뿐 아니라 동작도 보존해야 한다 | 제안, 실행, 검증을 분리하고 관찰 가능한 보존 계약을 정한다. | 컴파일, 테스트, 정적 검사, 구조 변화. | [제어 수단 의사결정표](https://aogavrilov.com/ko/projects/discrete-latent-generation/#control-surface) |

단계별 진단 안내서

## 압축 텍스트 생성의 코덱 병목

같은 외부 평가기로 재구성 손실과 잠재 생성 손실을 분리하고, 대리 지표 개선이 최종 텍스트로 전달되는지 확인한다.

코드 편집 방법 안내서

## 전체 재작성 없는 국소 코드 편집

선택적 재생성, 제약 생성, AI 보조 리팩터링, 계층적 잠재 제어를 비교하고 문법·구조·기능 보존의 차이를 구분한다.

## 이 사이트가 답할 수 있는 연구 질문

실제 질문의 짧은 답에서 시작해, 근거가 측정된 절과 한계를 직접 확인할 수 있다.

1. 생성 모델이 함수 전체를 다시 쓰지 않고 코드를 수정하려면 어떻게 해야 하는가? 생성 전에 편집 가능 경계를 정하고, 그 밖의 원본을 보존하거나 재사용하며, 후보 변경만 생성한 뒤 작업에 실패하거나 보호 영역을 바꾼 출력을 거부한다. 계층적 잠재 잠금은 실험적인 제어 수단 중 하나이지만 동일한 소스 구간을 보장하지는 않는다. [국소 편집 제어 수단 비교하기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#control-surface) .
2. 코드 편집이 단지 문법적으로 올바른 것이 아니라 국소적이라는 근거는 무엇인가? 요청 영역 밖의 diff를 작업 성공, 편집 영역의 변화, 구조 불변량, 테스트 또는 정적 검사, 반복 실행 변동성과 함께 측정한다. 파싱 성공률만으로 확인되는 것은 문법적 형식 적합성뿐이다. [국소성 근거 점검표 보기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#measurement) .
3. 코드 편집의 국소성과 생성 다양성은 어떻게 함께 평가해야 하는가? 보호 영역의 안정성과 함께 편집 영역의 자유도와 후보 고유성을 보고한다. 입력을 그대로 복사하면 안정성은 높지만 작업 진전이 없고, 제한 없는 재작성은 변화를 늘리지만 국소성을 잃을 수 있다. [측정된 안정성-자유도 근거 보기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#evidence) .
4. 국소 코드 편집, 제약 생성, 프로그램 수리는 어떻게 다른가? 국소 편집은 무엇이 변하지 않아야 하는지에 초점을 두고, 제약 생성은 문법 소속 같은 형식 속성을 강제하며, 프로그램 수리는 결함 또는 작업 명세를 만족해야 한다. 문법만으로 의미 동등성, 기능 정확성, 작업 성공, 국소성을 증명할 수 없다. [세 목표 비교하기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#comparison) .
5. Python 함수의 일부만 다시 생성하면서 나머지를 안정적으로 유지하려면 어떻게 해야 하는가? 생성 전에 보호 영역과 편집 영역을 정하고 편집 가능한 표현만 수정한 뒤 디코딩한다. 보호 코드를 바꾸거나 문법, 테스트, 정적 검사, 작업별 불변량에 실패한 후보는 거부한다. 보고된 계층적 잠재 실험은 64토큰 함수에서 확률적 안정성을 측정했을 뿐 동일 구간이나 동작을 보장하지 않는다. [선택적 재생성 절차 보기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#workflow) .
6. 동작 보존형 AI 보조 리팩터링에는 어떤 제어 전략이 맞는가? 가능하면 모델은 변환을 찾거나 제안하는 데 사용하고, 실행은 신뢰할 수 있는 리팩터링 엔진에 맡긴다. 이후 컴파일, 테스트, 정적 검사, 의도한 리팩터링 탐지를 확인한다. 그럴듯한 생성 패치만으로는 충분한 근거가 아니다. [리팩터링 의사결정 행 보기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#control-surface) .
7. 코드 생성을 단순히 제어 가능하게가 아니라 예측 가능하게 만드는 것은 무엇인가? 생성기를 고르기 전에 관찰 가능한 보존 계약과 합격 검사를 명시한다. 예측 가능성은 프롬프트, 마스크, 문법, 잠재 코드를 고정했는지가 아니라 디코딩과 검증 뒤 무엇이 안정적으로 남았는지에 달려 있다. [보존 계약 정의하기](https://aogavrilov.com/ko/projects/discrete-latent-generation/#core-idea) .
8. 보고된 텍스트 실험에서 코드 공간과 토큰 공간 마스크 확산은 어떻게 비교됐는가? 같은 외부 평가기에서 코드 공간 MDLM의 중앙값 perplexity는 26.55, 토큰 공간 기준선은 38.42로 30.9% 낮았다. 그러나 코덱 재구성 중앙값이 이미 27.36이었으므로 재구성 병목과 함께 해석해야 한다. [단계별 수치 확인하기](https://aogavrilov.com/ko/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
9. 코덱이 손실을 일으킬 때 코드 공간과 토큰 공간 마스크 확산은 어떻게 비교해야 하는가? 같은 보류 샘플과 디코딩 텍스트 평가기를 원문, 코덱 재구성, 토큰 공간 출력, 코드 공간 출력에 사용한다. 더 강한 잠재 생성기도 코덱이 이미 제거한 정보를 복구할 수 없으므로 재구성 격차를 따로 보고한다. [하나의 평가기로 단계 비교하기](https://aogavrilov.com/ko/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
10. 2단계 텍스트 생성기의 품질 손실은 어떻게 진단할 수 있는가? 변경하지 않은 하나의 디코딩 텍스트 평가기에서 원문-재구성 격차를 먼저, 재구성-생성 격차를 다음으로 측정한다. 그러면 코덱이 정한 품질 상한과 잠재 생성기가 추가한 저하를 분리할 수 있다. [4개 체크포인트 진단 따라가기](https://aogavrilov.com/ko/projects/codec-bottleneck-diagnosis/#workflow) .
11. 잠재 공간 지표가 좋아져도 디코딩 출력이 개선되지 않을 수 있는 때는 언제인가? 잠재 대리 지표가 최종 관심 속성을 추적하지 않으면 값만 개선될 수 있다. 일치하는 출력을 디코딩하고 같은 최종 지표로 평가해 전달 여부를 확인해야 한다. 그렇지 않으면 코드북 기하나 사용률은 진단 근거일 뿐 텍스트 품질 향상이 아니다. [대리 지표 전달 진단 사용하기](https://aogavrilov.com/ko/projects/codec-bottleneck-diagnosis/#decision-table) .

## 경계가 명확한 두 가지 실험 근거

아래 수치는 측정된 범위를 설명하며 다른 데이터나 시스템 전체로 일반화하는 보장이 아니다.

### 압축 파이프라인 진단

TinyStories 64→16 설정에서 중앙값 perplexity는 원문 **15.17** , 재구성 **27.36** 이었다. 같은 평가기에서 코드 공간 MDLM은 **26.55** , 토큰 공간 기준선은 **38.42** 였다.

### 점검 가능한 편집 제어

64토큰 Python 함수 설정에서 상위 잠재 코드 네 개를 잠갔을 때 파싱 성공률은 **0.453** 에서 **0.591** 로 올랐고, 잠그지 않은 위치의 변화율은 **0.936** , 조건부 샘플 고유성은 **0.998** 이었다.

## 이 방법 지도가 주장하지 않는 것

보고된 실험은 정확한 AST 보존, 의미 동등성, 기능 정확성, 저장소 규모 수리, 모든 압축 설정에서의 보편적 병목을 증명하지 않는다. 여기서는 제한된 근거를 재사용 가능한 진단 절차로 정리하며, 새 시스템은 자체 디코딩 출력과 동작 수준 검증을 거쳐야 한다.