P7-4.3 표현 정규화 연습¶
Section ID:
P7-4.3Version:v2026.08.01
표현 정규화 연습은 raw_expression, normalized_expression, coverage_change, prediction_change, remaining_oov, review_decision을 함께 남깁니다. 정규화가 늘 좋은 것이 아니라 어떤 신호를 살리고 잃는지 봐야 합니다.
낯선 표현을 학습 때 본 표현으로 바꾸면 실제로 무엇이 달라지는가를 직접 실험해 볼 차례입니다. 정규화 규칙 하나가 예측, coverage, 회고 우선순위를 어떻게 함께 바꾸는지 확인하는 연습입니다.
같은 고객 문의를 정규화 전과 정규화 후로 나누어 다시 실행하면 캔슬, 스케줄, 하자처럼 실제 운영에서 흔하지만 학습 어휘와 어긋나는 표현을 어떻게 다뤄야 하는지 보입니다. 기록에는 무엇을 바꿨고 무엇이 좋아졌는지가 남아야 합니다.
표현 정규화가 바꾸는 출력¶
- 표현 정규화(normalization)는 텍스트 분류 실습에서 무엇을 바꾸는가?
- 같은 문의를 정규화 전후로 비교하면 coverage와 예측은 어떻게 달라지는가?
- 어떤 표현을 먼저 사전에 추가할지 어떤 기준으로 정할 수 있는가?
핵심은 동의어 또는 운영 표현을 학습 어휘에 가까운 표현으로 치환했을 때 모델이 읽는 단어와 회고 문장이 어떻게 달라지는지 확인하는 데 있습니다. 여기서 먼저 봐야 할 것은 거대한 전처리 파이프라인이 아니라, 표현 하나의 차이가 coverage와 예측 해석을 얼마나 바꾸는가입니다.
판단 기준¶
- 정규화 전후 결과를 나란히 비교하는 실행 기록을 만들 수 있습니다.
- coverage 개선과 정답 개선이 항상 함께 움직이지는 않는다는 점을 설명할 수 있습니다.
- 어떤 표현을 우선 정규화할지
오답 빈도,핵심 의도성,운영 영향기준으로 정리할 수 있습니다.
왜 연습 절로 분리하는가¶
P7-4.2까지 읽고 나면 낮은 coverage 샘플은 다시 봐야 한다는 판단은 이해할 수 있습니다. 하지만 실제 프로젝트에서는 거기서 멈추지 않고, 무엇을 어떻게 바꿔 볼 것인가까지 바로 이어져야 합니다.
이 장면을 설명 절 안에 짧게 넣는 것만으로는 부족한 이유는 다음과 같습니다.
| 질문 | 설명 절만 읽을 때 | 연습 절까지 수행할 때 |
|---|---|---|
캔슬이 왜 문제인가 | OOV라고 이해함 | 취소로 바꾸었을 때 점수와 예측이 어떻게 달라지는지 확인함 |
스케줄은 왜 다시 봐야 하는가 | coverage가 낮다고 이해함 | 정답은 맞아도 정규화가 회고 우선순위를 낮출 수 있음을 확인함 |
| 무엇을 먼저 고칠 것인가 | 막연한 개선 아이디어만 남음 | 실제 비교표를 보고 우선순위를 정함 |
예를 들어 정규화 후 정확도가 1.0으로 올라가면, 빠르게는 동의어 사전만 더 늘리면 텍스트 문제는 대부분 해결된다고 적고 싶어질 수 있습니다. 하지만 더 안전한 다음 판단은 정확도 상승만 보는 것이 아니라, 평가-05처럼 실제 오답을 만든 표현이 무엇이었는지, 평가-07처럼 정답은 유지됐지만 coverage를 깎은 표현이 무엇인지, 정규화 뒤에도 남는 OOV가 무엇인지를 먼저 나누는 것입니다. 그렇게 읽어야 효과가 큰 규칙과 나중에 정리해도 되는 규칙을 구분할 수 있습니다.
flowchart TD
A["문제 장면<br/>정규화 후 정확도 1.0"]
B["피해야 할 빠른 판단<br/>동의어 사전만 늘리면 충분하다"]
C{"원문 정답 샘플이<br/>오답 또는 판단 보류가 되었는가?"}
D["규칙 되돌리기 또는 재검토<br/>coverage 개선보다 먼저 막는다"]
E{"원문 오답 또는 보류가<br/>정규화 뒤에도 남는가?"}
F["규칙 또는 데이터 보강<br/>coverage 상승만으로 통과하지 않는다"]
G["오답 유발 표현 확인<br/>무엇이 실제 오답을 만들었는가"]
H["low-coverage 정답 확인<br/>정답이지만 왜 다시 봐야 하는가"]
I["잔여 OOV 확인<br/>정규화 뒤에도 무엇이 남는가"]
J["더 안전한 판단<br/>표현 정규화 우선순위를 나눈다"]
A --> B
A --> C
C -->|예| D
C -->|아니오| E
E -->|예| F
E -->|아니오| G --> H --> I --> J
즉, 이 연습의 역할은 표현 문제를 알았다에서 끝나지 않고, 표현 문제를 어떻게 실험으로 다룰 것인가까지 손으로 닫는 데 있습니다.
입력 파일¶
- 파일 경로:
p7-4-support-routing-dataset.csv - 한 행의 의미:
한 건의 고객 문의와 라우팅 정답 - 이번 연습에서 특히 볼 평가 행:
평가-05,평가-07
고객 문의를 원문 문장과 정규화한 문장으로 나눠 같은 평가 셋에서 비교합니다. 핵심은 입력 파일 재사용이 아니라, 표현 하나를 바꿨을 때 coverage와 예측이 어떤 식으로 함께 흔들리는지 확인하는 데 있습니다. 아래 코드는 docs/ 폴더가 보이는 책 저장소 루트에서 실행합니다.
| 평가 샘플 | 원문 | 이번 연습에서 주목할 표현 |
|---|---|---|
| 평가-05 | 캔슬 후 송장 남아 있어요 | 캔슬 |
| 평가-07 | 하자 제품 환불 스케줄 알고 싶어요 | 하자, 스케줄 |
연습 흐름¶
flowchart TD
A["원문 문의"]
B["정규화 규칙 적용<br/>캔슬→취소<br/>스케줄→일정<br/>하자→불량"]
C["정규화 전후 토큰 비교"]
D["coverage와 예측 비교"]
E["무엇을 먼저 고칠지 기록"]
A --> B --> C --> D --> E
이 흐름에서 중요한 점은 정규화 규칙을 많이 만드는 것이 아니라, 하나의 규칙이 어떤 샘플에서 어떤 변화를 만들었는지 분리해서 읽는 것입니다.
실행 기록 기준¶
- 정규화 규칙을 적용하지 않은 결과와 적용한 결과를 같은 평가 셋에서 비교합니다.
coverage,예측 팀,정답 여부,남은 OOV,검토 결정이 어떻게 바뀌는지 샘플별로 적습니다.- 바뀐 결과를 보고
어떤 표현을 다음 데이터 정리 우선순위로 올릴지한 문단으로 정리합니다.
Python 예제¶
예제는 정규화 전후 비교표를 바로 얻는 것입니다. 코드가 길어 보이더라도 실제로는 토큰화와 분류 흐름은 유지한 채, 정규화 규칙 적용 단계가 coverage와 예측 해석을 어떻게 바꾸는지 드러내는 형태입니다.
- 문제 상황: 고객 문의의 낯선 표현이 라우팅 결과를 흔든다.
- 비교 대상: 원문 문장 vs 정규화 후 문장
- 기대 출력: 샘플별 coverage 변화, 예측 변화, 정규화 효과 요약
- 확인할 개념:
- 정규화는 입력 표현을 학습 어휘에 더 가깝게 만드는 작업이다
- coverage가 올라가도 예측이 그대로일 수 있다
- 정규화 우선순위는
오답을 만든 표현부터 잡는 편이 실무적이다
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 | |
실행 결과 예시는 다음과 같습니다.
결과를 어떻게 읽는가¶
이번 비교에서 먼저 읽어야 할 것은 정확도 1.0이 아니라, 어떤 표현을 바꿨더니 무엇이 달라졌는가입니다.
| 샘플 | 정규화 전 | 정규화 후 | 검토 결정 |
|---|---|---|---|
| 평가-05 | coverage 0.2, 배송팀 오답 | coverage 0.4, 환불팀 정답 | 우선 정규화: 캔슬은 실제 오답을 만들었다 |
| 평가-07 | coverage 0.333, 환불팀 정답 | coverage 0.667, 환불팀 정답 유지 | 다음 정리 후보: 하자, 스케줄은 coverage만 낮췄다 |
이 비교를 통해 다음 네 가지 정규화 판단 경우를 구분할 수 있습니다.
오답을 직접 만든 표현: 먼저 고쳐야 합니다. 예제에서는캔슬이 여기에 해당합니다.정답은 유지됐지만 coverage를 낮춘 표현: 다음 우선순위로 둘 수 있습니다. 예제에서는하자,스케줄이 여기에 가깝습니다.정답을 오답 또는 판단 보류로 바꾼 규칙: coverage가 올라도 먼저 되돌리거나 다시 검토해야 합니다. 이 경우에는규칙 되돌리기 또는 재검토로 기록합니다.오답 또는 판단 보류가 그대로 남은 규칙: coverage가 올라도 오류가 해결되지 않았으므로규칙 또는 데이터 보강으로 기록합니다.
즉, 정규화 우선순위는 단순히 OOV 개수만으로 정하기보다 실제 운영 판단을 틀리게 만들었는가를 먼저 봐야 합니다. 특히 정규화 전에는 맞았는데 정규화 후에 틀리거나 보류가 된 샘플, 또는 정규화 뒤에도 오답·보류가 남은 샘플은 coverage 개선보다 앞서 확인합니다.
결과 해석 기준¶
- coverage가 올라갔는데도 예측이 안 바뀌는 샘플은 무엇인가?
- 예측이 바뀐 샘플은 어떤 단어 하나가 핵심 신호였는가?
- 정규화로 해결되지 않고 여전히 남는 OOV는 무엇인가?
- 다음 데이터 정리에서는
동의어 사전 추가,학습 데이터 보강,토큰화 방식 변경중 무엇을 먼저 시도할 것인가?
프로젝트 기록 예시¶
실습 뒤에는 다음 형식으로 짧게 기록해 두는 편이 좋습니다.
| 항목 | 적을 내용 |
|---|---|
| 사실 | coverage 변화, 예측 변화, 원문·정규화 후 정답 여부는 무엇인가 |
| 해석 | 남은 OOV는 무엇이며 그 변화가 표현 불일치 때문이었는가, 점수 우연이었는가 |
| 다음 질문 | 우선 정규화, 다음 정리 후보, 규칙 또는 데이터 보강, 규칙 되돌리기 또는 재검토 중 무엇으로 기록할 것인가 |
한 문단으로 쓰면 예를 들어 다음처럼 정리할 수 있습니다.
캔슬 후 송장 남아 있어요는 원문에서는 배송팀으로 잘못 분류됐지만,캔슬을취소로 정규화하자 coverage가 0.2에서 0.4로 오르고 예측도 환불팀으로 바뀌었다. 반면하자 제품 환불 스케줄 알고 싶어요는 정답은 유지됐지만 coverage가 0.333에서 0.667로 올라, 지금은 맞더라도 표현 정규화 가치가 있는 샘플임을 확인했다. 따라서 다음 반복에서는 실제 오답을 만든 동의어부터 우선 사전에 추가하고, 그 뒤에 low-coverage 정답 샘플을 정리하는 편이 적절하다.
직접 바꿔 보며 확인할 것¶
각 실습은 기본 CSV와 기본 normalization_map에서 시작하는 독립 실행입니다. 지시한 sample_id 행의 text 열 또는 정규화 규칙만 수정하고 실행한 뒤, 다음 실습 전에는 원래 문장과 규칙으로 되돌립니다.
-
평가-05를캔슬 후 남아 있어요로 바꿔 다시 실행해 봅니다. 관찰할 점: 원문 coverage는0.000이고 예측은판단 보류, 정규화 후 coverage는0.250이고 예측은 환불팀 정답이 됩니다. 요약의원문 판단 보류 샘플에는평가-05가, 정규화 후 목록에는 아무것도 남지 않습니다. 원문에는 학습 어휘가 하나도 없어 두 팀 점수가 동률입니다. 이 예제는 그 동률을 첫 라벨의 정답처럼 처리하지 않으므로,캔슬정규화가 모델에 환불 신호를 다시 제공했다는 사실을 분리해 읽을 수 있습니다. -
평가-07에 새 표현 하나를 더 넣어 봅니다. 예를 들어하자 제품 환불 스케줄 ASAP처럼 바꿔 봅니다. 관찰할 점: 원문 coverage는0.400, 정규화 후 coverage는0.800이지만ASAP는 정규화 뒤에도 OOV로 남습니다. 예측은 환불팀 정답으로 유지되므로, 이 표현은 즉시 오답을 고치기보다 사전 추가 또는 토큰화 검토 대상으로 기록합니다. -
평가-07을하자 제품 환불 요청 스케줄 알고 싶어요로 바꾸고, 정규화 규칙에"환불 요청": "환불"을 추가해 봅니다. 관찰할 점: 정규화 후 문장에서요청이 사라지고 coverage가0.429에서0.667로 오르는가? 정규화 함수는 긴 표현부터 공백 경계에서 치환하므로,환불 요청은 한 표현으로 적용되고환불 요청서같은 더 긴 토큰 내부는 바꾸지 않습니다. 예측이 그대로라면 규칙 추가는 coverage 개선 기록으로 남기고, 실제 오답 감소는 별도 평가에서 확인합니다. -
기본
평가-07을 유지한 채, 정규화 규칙에"환불": "배송"을 추가해 봅니다. 관찰할 점: 원문 coverage0.333, 환불팀 정답이 정규화 뒤 coverage0.667, 배송팀 오답으로 바뀌는가? coverage가 올라도검토 결정은규칙 되돌리기 또는 재검토여야 합니다. 이 규칙은 의도적으로 잘못된 예이므로 실행 뒤 바로 제거합니다. -
기본
평가-05를 유지한 채, 정규화 규칙에"취소": "배송"을 추가해 봅니다. 관찰할 점: 원문 coverage0.2, 배송팀 오답이 정규화 뒤 coverage0.4, 배송팀 오답으로 남는가? coverage는 올랐지만 오류가 해결되지 않았으므로검토 결정은규칙 또는 데이터 보강이어야 합니다. 이 규칙도 의도적으로 잘못된 예이므로 실행 뒤 바로 제거합니다.
판단 기준은 coverage가 올랐다는 사실만이 아니라, 그 변화가 실제 오답을 줄였는지입니다. 먼저 정답이 오답·보류로 바뀐 규칙은 되돌리거나 다시 검토하고, 오답·보류가 남은 규칙은 데이터 또는 규칙을 보강합니다. 그다음 오답을 정답으로 바꾼 표현을 우선 정규화 후보로 올리고, 정답은 유지됐지만 coverage만 낮춘 표현은 다음 정리 우선순위로 둡니다.
체크리스트¶
| 확인할 것 | 스스로 답할 질문 |
|---|---|
| 비교 조건 | 정규화 전후를 같은 평가 셋에서 나란히 실행했는가? |
| coverage | coverage 변화와 예측 변화를 함께 기록했는가? |
| 오류 표현 | 오답을 만든 표현과 low-coverage 정답 표현을 구분했는가? |
| 정답 회귀 | 정답이 정규화 뒤 오답 또는 판단 보류가 된 샘플을 되돌리기 또는 재검토 대상으로 표시했는가? |
| 오류 잔존 | 정규화 뒤에도 오답 또는 판단 보류가 남은 샘플을 규칙 또는 데이터 보강 대상으로 표시했는가? |
| 남은 위험 | 정규화 후에도 남는 OOV나 애매한 표현을 적었는가? |
| 다음 반복 | 무엇을 먼저 바꿀지 한 문장으로 정했는가? |
출처와 참고 자료¶
- 문의 데이터:
p7-4-support-routing-dataset.csv - 이 문서는 자체 실습 예시를 사용했습니다. 외부 자료를 직접 인용하지 않았습니다.