요약 — AI를 위한 데이터 클리닝은 BI 툴링에서 가져온 일회성 배치 작업처럼 취급되지만, 실제 실패 모드는 잘못된 모델 출력으로부터 그 원인이 된 소스 레코드까지의 흔적을 잃어버리는 것입니다. 클리닝(Cleaning), 청킹(Chunking), 임베딩(Embedding)은 기본적으로 출처 정보(provenance)를 지우는 손실성 변환(lossy transforms)입니다. 모델에 데이터를 안정적으로 공급하는 파이프라인에는 규정 준수를 위해 나중에 붙이는 것이 아니라, 일급 시민(first-class) 레이어로서 계보가 필요합니다.

사용자가 물려받은 모든 데이터 품질 체크리스트는 다른 소비자들을 위해 만들어졌습니다. Null 검사, 중복 제거, 스키마 유효성 검사, 참조 무결성 — 이것은

청크가 벡터 스토어에 저장될 시점에는 원본 문서로부터 여러 번의 변환을 거친 상태입니다. 만약 이 청크가 나중에 프롬프트로 검색되어 환각(hallucinated)되거나 미묘하게 잘못된 답변을 생성한다면, 이를 추적하려면 아무도 기록하지 않은 체인(chain)을 재구성해야 합니다. 즉, 어떤 원본 문서였는지, 그 문서의 어떤 버전이었는지, 어떤 클리닝 과정이 거쳤는지, 어떤 청킹 매개변수를 사용했는지, 그리고 어떤 임베딩 모델 체크포인트가 사용되었는지를 알아내야 합니다. 실제로는 거의 아무도 이 체인을 재구성할 수 없습니다. 따라서 디버깅의 기본 방식은 전체 코퍼스(corpus)를 손으로 다시 읽어보거나, 더 나쁜 경우 증상이 사라질 때까지 프롬프트를 조정하다가 실제 원인이 묻혀 있는 상태로 방치하는 것입니다.

이것이 대부분의 '데이터 클리닝' 조언에서 놓치는 부분입니다. 목표는 단순히 모델에 도달하기 전에 쓰레기를 제거하는 것이 아닙니다. 그것은 살아남은 주어진 데이터 조각이 왜 그런 모양을 하고 있는지 나중에 설명할 수 있는 능력을 잃지 않으면서 쓰레기를 제거하는 것입니다. 이것들은 서로 다른 엔지니어링 문제입니다. 그리고 두 번째 문제, 즉 '설명 가능성'을 확보하는 것이 실제로 AI 시스템이 프로덕션 환경에서 디버깅 가능한지를 결정합니다.

계보(Lineage)가 누락된 레이어

데이터 엔지니어링에는 이 추상적인 개념에 대한 성숙한 답변, 즉 '계보(lineage)'가 있습니다. 데이터가 어디서 왔는지, 무엇이 그것을 변환했는지, 그리고 무엇으로 바뀌었는지를 추적하는 것입니다. 이러한 학문 분야 자체가 존재합니다. 다만 AI 시스템에서는 계보 도구가 '어떤 대시보드에 데이터를 공급하는지'를 답하도록 만들어졌기 때문에, 실제로 '추론 시점에 이 특정 모델 출력에 어떤 데이터가 공급되는지'를 묻는 상황까지는 거의 적용되지 않습니다.

모델에 신뢰성 있게 데이터를 공급한다는 것은 계보가 전통적인 데이터 계보 도구들이 설계되지 않은 세 가지 변환을 견뎌내야 함을 의미합니다. 즉, 단순히 행(row)을 필터링하는 것이 아니라 콘텐츠를 다시 작성하는 클리닝 과정, 자연스러운 키가 없이 하나의 레코드를 여러 개로 분할하는 청킹 과정, 그리고 텍스트를 어떤 인간이 읽을 수 있는 추적도 없는 벡터로 변환하는 임베딩 과정입니다. 만약 여러분의 계보 그래프가 '원본 문서가 수집됨'에서 멈춘다면, 파이프라인의 쉬운 20%에 대한 계보는 있지만, 실제로 모델이 보는 것을 형성하는 부분에 대해서는 아무것도 없다는 뜻입니다.

실제 구현에서 이것이 실제로 어떻게 보이는가

계보(Lineage)-우선 파이프라인은 특이한 인프라를 필요로 하지 않습니다. 그것은 대부분의 팀들이 오버헤드처럼 느껴져 건너뛰는 몇 가지 규율적인 습관들만 필요하며, 이 습관들은 나중에 당신에게 도움이 될 때까지 무시됩니다.

원본 소스(raw source)는 불변적이고 콘텐츠 주소 지정 방식(content-addressed)으로 유지해야 합니다. 그래야 모든 다운스트림 아티팩트가

계보(Lineage)를 무시하는 것은 깔끔한 실패로 나타나지 않습니다. 그것은 약간씩 다른 형태로 반복적으로 지불해야 하는 세금처럼 나타납니다. 평가(eval) 결과가 퇴행하고 아무도 이것이 모델 변경 때문인지, 프롬프트 변경 때문인지, 아니면 검색 파이프라인이 현재 반환하는 내용에 조용한 변화가 생겼기 때문인지 알 수 없습니다. 사용자가 사실과 다른 답변을 보고하면 사고 검토는 그것이 아마 어느 문서에서 왔는지 추측하는 것으로 구성됩니다. 소스 문서가 법적 또는 사실적으로 잘못되어 제거해야 하는데, 어떤 임베딩(embeddings), 어떤 파인튜닝 예제(fine-tuning examples), 또는 어떤 캐시된 출력물(cached outputs)이 그것으로부터 파생되었는지 알 방법이 없기 때문에, 제거는 '모든 것을 처음부터 다시 구축하고 바라보는 것'이 됩니다.

바로 이 부분이 주목받을 가치가 충분한데도 불구하고 그렇지 못합니다. AI 파이프라인에서 삭제(Deletion)는 DELETE 구문이 아닙니다. 소스 데이터의 조각 하나가 다운스트림에서 무엇에 영향을 미쳤는지 추적할 수 없다면, 그 영향력을 실제로 제거할 수 없습니다. 단지 행을 제거하고 모델이 잊어버리기를 바랄 뿐인데, 이는 검증 가능한 방식으로 보통 일어나지 않습니다. 계보는 단순히 디버깅의 편의성일 뿐만 아니라, 삭제(deletion), 수정(correction), 그리고 표적 재학습(targeted retraining)을 이론적인 것이 아닌 실제로 가능하게 만드는 것입니다.

클리닝은 필요하지만 충분하지는 않다.

이 모든 내용은 데이터 클리닝을 반대하는 것은 아닙니다. 클리닝은 여전히 필요하며, 대부분의 파이프라인은 덜 하는 것이 아니라 더 많이 해야 합니다. 주장은 범위가 좁습니다. 클리닝만으로는 모델이 입력되는 과정에서 보는 것에 최적화할 뿐이지만, 계보는 모델이 출력되는 과정에서 무엇을 생성했는지 추론할 수 있게 해줍니다. 데이터 수집(ingestion) 단계에서는 완벽하지만 그 이후 지점부터 불투명한 파이프라인은 여전히 아무도 설명할 수 없는 방식으로 실패하게 되는데, 왜냐하면 실패가 가시성이 멈춘 곳으로부터 세 번의 변환(transforms) 다운스트림에서 나타나기 때문입니다.

AI 시스템을 프로덕션 환경에서 운영하는 데 더 쉬운 팀들은 가장 깨끗한 코퍼스(corpus)를 가진 팀들이 아닙니다. 그들은 어떤 출력물을 가리키며, 추측 없이 정확히 어느 소스 데이터 조각이 그것을 가능하게 했는지 말할 수 있는 팀들입니다.