인덱스 데이터 손상 진단
data/chroma_v2(30,002청크 / 99문서) 전수 측정. 검색 실험 골든셋 40문항 라벨링 중 사람 눈에 걸린 이상을 코퍼스 전체로 확대해 센 것.
| 결론 | 검색 실패 원인 중 알고리즘 문제는 1건, 나머지는 인제스트 손상 |
| 최대 손상 | 요구사항 고유번호 유실 31% (이전 45%에서 개선) |
| 미수정 | hwp 파싱 깨짐 345청크 · 가운뎃점 변종 5종 |
| 주의 | 재인덱싱하면 지금 라벨 35문항이 무효가 된다 |
[인제스트] [검색]
hwp/pdf → 추출 → 클리닝 → 청킹 → 임베딩 → | dense · BM25 · 리랭커
↑ 여기서 망가진 것 ↑ 우리가 실험하는 곳
인제스트에서 망가진 데이터는 검색 알고리즘을 바꿔도 안 고쳐진다. 이미 그 상태로 인덱스에 들어가 있다.
표 청킹 수정은 효과가 있었다
2026-07-27 재인덱싱 전/후를 동일한 잣대로 재측정한 결과다.
| 이전 (28,293청크) | 이후 (30,002청크) | ||
|---|---|---|---|
| 표로 인식된 청크 | 3,779 | 19,005 | 5배 |
| ├ 요구사항 표 | 588 | 10,342 | 17배 |
| ├ 그중 고유번호 없음 | 45.4% | 31.4% | −14%p |
| └ 표 머리 없는 조각 | 21.9% | 7.2% | 1/3 |
| 섹션 누락 | 6.1% | 4.8% | 개선 |
| hwp 파싱 깨짐 | 355 | 345 | 거의 그대로 |
가장 큰 변화는 두 번째 줄이다. 이전에는 요구사항 표를 표로 인식조차 못 했다(588개). 지금은 10,342개를 잡는다. 표 셀 헤더 승격·표 판정 일원화의 직접 효과다.
읽는 법 주의 — 고유번호 유실을 “30% → 31%, 개선 없음”으로 읽으면 틀린다. 분모(요구사항 표로 인식된 청크)가 588 → 10,342로 17배 커졌기 때문이다. 남은 31%는 이전엔 아예 보이지도 않던 영역까지 포함한 수치다. 같은 잣대로 재면 45.4% → 31.4%다.
hwp 깨짐만 안 줄었는데, 그건 청킹이 아니라 추출 단계 문제라 이번 수정 범위 밖이었다.
어떻게 발견했나 — 사람이 라벨링을 직접 해서
인제스트 손상은 지표로는 안 보였다. hit@5는 1.000이었고 청크 수·섹션 보유율 같은 인덱싱 지표도 정상이었다. 정답 청크 40문항을 사람이 눈으로 고르는 과정에서 하나씩 드러났다.
| 라벨링 중 관찰 | 추적한 원인 | 단계 | 상태 |
|---|---|---|---|
| ”26·17 둘 다 골라야 함” — BIT 사양표가 반으로 갈림 | 500자 경계가 표 중간을 자름 | 청킹 | 잔여 |
| ”고유번호로 찾았는데 그 청크에 답이 없음” | ID 행은 앞 청크, 내용은 뒤 청크 | 청킹 | 45%→31% |
| “25·26·27·28이 다 똑같아 보임” | 뒤 조각에 어느 표인지 표시 없음 | 청킹 | 22%→7% |
“楴䵴 때문에 정답을 못 알아봄” (EIP3.0) | hwp 파서가 제어 바이트를 문자로 출력 | 추출 | 미수정 |
| ”사회적 책임·성실성”이 문서마다 다른 문자 | 가운뎃점 5종 공존 | 클리닝 | 미수정 |
| ”표에 유형이 없다” (BIT 유형별 수량) | 정답이 후보 20개 밖 (dense 35위) | 검색 | 후보 깊이 |
| 타 문서 청크가 정답에 3건 혼입 | 후보 화면에 문서명 미표시 | 도구 | 감사로 제거 |
| 300자 절단으로 핵심 숫자가 안 보임 | 미리보기 길이 설정 | 도구 | 1,400자로 상향 |
라벨링은 수정본 인덱스로 진행했다. 후보 951개가 전부 chroma_v2에 있다(이전 인덱스엔 930개만). 즉 위 청킹 관찰들은 수정이 안 됐다는 뜻이 아니라, 크게 줄어든 뒤 남은 잔여분이다.
여기서 얻은 것
자동 지표로는 안 보였다. 사람이 “이 청크에 답이 있나?”를 40번 판단하고 나서야 표 절단·깨진 문자·유니코드 변종이 드러났다.
관찰을 원인 단계까지 추적해야 쓸모가 있다. “표가 이상하다”에서 멈추면 조치할 수 없다. 청킹/추출/클리닝/검색/도구 중 어디인지 가려야 무엇을 고칠지 정해진다. 실제로 8건이 청킹 3·추출 1·클리닝 1·검색 1·도구 2로 갈렸고 담당 파일이 전부 다르다.
개선분과 잔여분을 구분해서 말해야 한다. “고유번호 유실 31%“만 보면 실패로 읽히지만 이전은 45%였다.
검색 실험의 부산물이 인제스트 진단이 됐다. 원래 목적은 BM25·리랭커 비교였는데, 평가 데이터를 만드는 과정에서 나온 관찰이 더 실행 가능한 개선 목록을 만들어냈다.
전수 측정 결과
| 항목 | 건수 | 비율 | 심각도 |
|---|---|---|---|
| 요구사항 청크에 고유번호 없음 | 3,252 | 요구사항 표의 31% | 높음 |
| 거의 동일한 청크 | 6,712 (2,120그룹) | 22.4% | 중간 |
| 표 머리 없는 조각 | 1,367 | 표 청크의 7.2% | 높음 |
| 정보량 없는 짧은 청크 (<40자) | 3,002 | 10.0% | 중간 |
| 빈 셀이 절반 넘는 표 | 2,221 | 표 청크의 12% | 중간 |
| 섹션 경로 누락 | 1,437 | 4.8% | 중간 |
| hwp 파싱 깨짐 문자 | 345 | 1.1% (57개 문서) | 높음 |
NFC 미정규화 청크는 0건. 정규화 자체는 정상이다.
손상별 상세
1. 요구사항 고유번호 유실 — 31%
개선됐지만 여전히 최대 손상이다. 요구사항 표는 세로형 키-값 구조라, 500자에서 자르면 고유번호 행이 앞 청크에 남고 내용만 뒤 청크로 넘어간다.
::0059 | 요구사항 고유번호 | ECR-002 |
| 요구사항 명칭 | 버스정보안내단말기(BIT) 소형 |
| 세부내용 | ○ 도입장비 수량 ▹ 소형 쉘터형 : 50대 … ← 여기서 끊김
::0060 물(지지대 혹은 브라켓) 포함 도장 : 옥외용 분체도장 … ← "구조"의 "물"부터
"SFR-009 요구사항이 뭐야?" 같은 질문에서 내용 청크가 안 잡히고, 검색된 청크에 번호가 없어 출처 표기도 부정확해진다. 라벨링 중 “고유번호로 찾은 청크에 답이 안 보인다”의 직접 원인이다.
대응 — 잘린 조각마다 표 머리(고유번호·명칭 행)를 다시 붙인다. 규칙 변환이라 LLM 불필요.
2. 거의 동일한 청크 — 22.4%
앞 120자가 같은 청크가 2,120그룹 6,712개. 한 그룹 최대 80개다. 같은 양식의 표가 여러 벌 있고 뒤 조각에 식별자가 없어서 생긴다 — 1번과 뿌리가 같다.
지금 검색 실험에는 영향 없음. 정답이 중복 무리에만 있는 문항은 0건이고 중복은 대부분 오답 쪽에 몰려 있다. 다만 문서가 늘면 터질 수 있어 감시 대상이다. → 검색 실험 골든셋 40문항 교훈 B-④
3. hwp 파싱 깨짐 — 345청크 / 57문서
楴䵴楴䵴4. 제안요청 내용
가. 제안요청 개요
3) 사업금액 : 40,000천원(부가세 포함)
䵴·䛄·䱴·䖴 같은 CJK 확장 영역 문자가 청크 머리에 섞인다. hwp 바이너리 파싱에서 제어 바이트를 문자로 잘못 해석한 것이다. 목차의 점선 자리와 글머리표 자리에 집중적으로 나타난다.
청킹이 아니라 추출 단계 문제라 이번 표 수정으로는 안 줄었다(355 → 345, 영향 문서 57개 동일).
라벨링 중 사람이 정답 청크를 못 알아보고 건너뛴 실제 사례가 있다(EIP3.0 사업금액). 임베딩에도 노이즈로 들어간다.
대응 — 클리닝에서 해당 유니코드 영역 제거. 정규식 한 줄이면 되고, 한국어 RFP 본문에 이 영역 문자가 정상적으로 등장할 일은 없다.
4. 빈 셀 과다 표 — 표 청크의 12%
병합셀을 빈칸으로 패딩한 결과, 셀 절반 이상이 빈 표가 2,221개다.
| | | |
| --- | --- | --- |
| | 2024년 ｢벤처확인종합관리시스템…｣ | |
| | | |
임베딩에 파이프·구분선만 들어가 의미 신호가 희석된다. dense가 표에서 약한(표 10위 vs 줄글 4위) 원인 중 하나로 추정된다.
대응 — 빈 셀 압축 또는 표를 행 단위 문장으로 변환. 후자는 검색 품질에도 직접 기여한다.
5. 가운뎃점 유니코드 변종 — 5종 공존
| 문자 | 코드 | 청크 |
|---|---|---|
· | U+00B7 | 4,149 |
․ | U+2024 | 1,699 |
‧ | U+2027 | 558 |
∙ | U+2219 | 92 |
・ | U+30FB | 51 |
사회적 책임·성실성과 사회적 책임∙성실성이 다른 문자열이라 BM25 정확 매칭이 깨진다. NFC 정규화로는 안 잡히고(NFC 미정규화 0건) 별도 치환이 필요하다.
6. 짧은 청크 · 섹션 누락
40자 미만 청크 3,002개(표 조각·빈 줄·제목 단독)는 검색 결과 자리를 차지하면서 답에 기여하지 않는다. 섹션 메타가 없는 청크 1,437개는 출처가 chunk_id로 대체돼 사람이 읽을 수 없다.
대응 우선순위
| 작업 | 난이도 | 기대 효과 | |
|---|---|---|---|
| 1 | 표 머리 반복 삽입 | 중 | 고유번호 유실 31% + 중복 청크 22% 동시 해결 |
| 2 | hwp 깨짐 문자 제거 | 하 | 345청크, 정규식 한 줄 |
| 3 | 가운뎃점 통일 | 하 | BM25 정확 매칭 복구 |
| 4 | 표 행 단위 문장화 | 중 | dense의 표 약세 개선 (10위 vs 4위) |
| 5 | 짧은 청크 병합·제외 | 하 | 검색 결과 자리 낭비 감소 |
2·3번은 오늘 안에 가능하고 재인덱싱만 하면 된다. 1·4번은 청킹 로직 변경이라 설계가 필요하다.
주의 — 재인덱싱은 라벨을 무효화한다
청크 ID가 {doc_id}::{순번}이라 청킹이 바뀌면 전부 달라진다. 지금 라벨 35문항이 무효가 되므로 검색 실험 측정을 먼저 끝낸 뒤 진행해야 한다.
1. 7변형 측정 → 베이스라인 확보 ← 현재 여기
2. 인제스트 수정 → 재인덱싱 → 재라벨링
3. 재측정 → "검색 개선 vs 데이터 개선" 비교
이러면 알고리즘에 투자할지 데이터에 투자할지가 숫자로 갈린다.