Series: AI 검증이 놓치는 것들
AI가 만든 결과물을 다시 검증하는 장치 자체를, 그 장치가 실제로 뭘 놓치는지 실측으로 들여다본 기록. 상위개념과 하위유형을 동일 대상으로 오판한 병합 감사 장치, 리스트 밀도가 높은 파일에서 항목별 대조 없이 훑어보기만 한 서브에이전트 전수 감사, 다른 사례로만 재검증하느라 원래 오탐 사례는 다시 안 본 것, ingest 단계에서 형제 노트끼리 문단을 그대로 베끼는 걸 처음엔 아무 장치도 못 잡았던 것, 그리고 그 중복을 잡으려 새로 만든 임베딩 필터조차 모델 등급(small/large)에 따라 판정이 뒤집히는 것, 그 필터를 걷어내자 '깨끗하다'고 기록해 둔 묶음에서도 중복이 나온 것, 병합 규칙의 틀린 예시만 지우고 그 예시를 낳은 규칙은 남겨 둔 것, 실제 노트 테스트는 깨끗하게 통과했지만 고친 코드는 한 번도 실행되지 않은 것, 중복을 지운 뒤 남은 문장이 가리킬 곳을 잃는 깨짐을 모양마다 코드로 막다가 LLM이 고친 노트를 다시 읽어 판정하는 쪽으로 바꾼 것까지.
-
몇 주 뒤, 그 감사 장치가 못 보는 경우를 찾았다
예전에 32번 중 32번을 다 맞혔던 병합 감사 장치가, 실전에서 상위 개념 노트와 그 하위 유형 노트를 동일 대상으로 오판했다. 원인은 판단력이 아니라 설계 자체 — 그 감사는 처음부터 이 종류의 오판을 잡도록 만들어진 게 아니었다.
-
리스트 밀도 상위 4개 중, 서브에이전트가 2개를 놓쳤다
Claude Code 서브에이전트에게 맡긴 전수 감사가 56개 파일 중 2개를 CLEAN으로 잘못 보고했다. 불릿 리스트가 많은 파일에서 '다 읽었다'는 판정이 항목별 대조가 아니라 뭉뚱그린 훑어보기였다는 걸 프롬프트 A/B 테스트로 확인하고, 체크리스트를 강제하는 프롬프트로 고친 기록.
-
검증은 다른 쌍으로 했는데, 원래 그 사례는 다시 안 봤다
Obsidian 플러그인의 LLM 병합 판단 프롬프트에서 오탐을 고치고 GitHub 이슈까지 닫았는데, 정작 오탐을 일으켰던 원래 사례는 그 사이 한 번도 다시 테스트하지 않았다. 며칠 뒤 실제 vault 전체 조건으로 돌려보니 판단이 뒤집혔고, 실제로 병합해보니 원래 판단 자체가 틀렸을 가능성이 높았던 기록.
-
LLM이 만든 형제 노트끼리 같은 문단을 그대로 베끼고 있었다
Obsidian 플러그인 테스트를 실제 기사로 바꾸자, LLM이 기사 한 편으로 만든 형제 노트끼리 같은 문단을 그대로 복사하는 버그가 드러났다. 임베딩 기반 중복 탐지도 이 중복은 못 잡았다.
-
임베딩 모델을 바꾸니 순서가 뒤집혔다
OpenAI 임베딩 모델을 text-embedding-3-small에서 large로 바꾸자, 코사인 유사도 0.72~0.80에 뒤섞여 있던 진짜 중복 문단과 우연히 비슷한 문장의 순서가 뒤집혔다.
-
임베딩 필터를 걷어내니, 중복이 오히려 더 많이 잡혔다
LLM이 만든 형제 노트의 중복을 잡던 임베딩 후보 필터를 걷어내고 노트 전체를 한 번에 LLM에 맡겼다. 허브 노트 예외 조항 하나로 정밀도가 55%에서 100%가 됐고, 깨끗하다던 묶음에서도 중복이 나왔다.
-
LLM 노트 병합 규칙에서 틀린 예시는 지웠는데, 규칙은 남아 있었다
Obsidian 플러그인의 LLM 중복 노트 병합 규칙이 같은 제품 노트까지 막고 있었다. 규칙의 출처를 따라가 실제로 병합해 보니 근거가 없었고, 카파시 LLM Wiki처럼 같은 대상이면 합치는 기준으로 바꿨다.
-
LLM 노트 병합 테스트는 통과했는데, 고친 코드는 한 번도 실행되지 않았다
Obsidian 플러그인의 LLM 노트 병합 버그를 고치고 실제 노트로 다시 돌렸다. 결과는 깨끗했지만 고친 코드가 지나갈 장면이 아예 생기지 않았고, 병합 직전 상태를 복원하고서야 확인했다.
-
LLM이 노트 중복을 지우자, 남은 문장이 가리킬 곳을 잃었다
LLM으로 노트 중복을 지우자 '이 기술 체계', '또한'처럼 앞 문장을 가리키던 말이 대상을 잃었다. 코드 규칙으로 막다 멈추고, 고친 노트를 LLM이 다시 읽어 판정하게 했다.