존재하지 않던 테이블

2장 — 존재하지 않던 테이블

북동부의 기계 회사 기술자가 에스프레소 한 잔과 함께 차분하게 이야기해 주었습니다. 베네치아 사람 특유의 침착함은 재앙을 예고하는 듯했습니다. “저희 챗봇은 엔진에 대한 모든 것을 알고 있었습니다. 엔진 데이터만 빼고요.” 그는 설명을 덧붙였습니다. 그들의 내부 AI 어시스턴트는 제품 라인업, 사용 사례, 브랜드 스토리, 경쟁 우위 등을 설명할 수 있었습니다. 서사적인 측면에서는 놀라웠습니다. 하지만 고객이 CMP50L 모델의 정격 토크(사람들이 카탈로그를 열고 엔진을 구매하는 데 사용하는 데이터)를 묻자 챗봇은 모호하게 답변하거나, 때로는 그럴듯하게, 때로는 그렇지 않게 대답했습니다. 5개월간의 개발, 점점 더 당황하는 운영 이사, 그리고 그 이유를 아는 사람은 아무도 없었습니다.

진단은 우연히, 거의 지루함을 느껴 데이터베이스를 손으로 검사하던 중, 또다시 결론 없는 회의 후에 내려졌습니다. PDF 카탈로그에는 342개의 기술 테이블이 들어 있었습니다. 데이터베이스에는 단 0개도 도착하지 않았습니다. 몇 개가 아니라, 0개입니다. 하나도 없습니다. PDF에서 테이블을 추출하는 코드는 columns 및 data라는 필드에 데이터를 저장했지만, 나중에 해당 테이블을 인덱싱하는 코드는 headers 및 rows라는 필드를 예상했습니다. 지켜지지 않은 "동의어". 잊혀진 리팩토링에서 깨진 내부 규칙입니다. 그 결과, 5개월 동안 조용히 — 카탈로그의 모든 숫자 정보, 즉 쌍, 전력, 직경, 무게, 주문 코드, 공급 전압 — 는 수도꼭지에서 흘러나왔지만 결코 잔에 따르지 않았습니다. 342개의 테이블이 조용하고 의례적인 방식으로 하나씩 사라졌습니다.

이것은 소리를 지르지 않는 버그의 유형입니다. 예외를 발생시키거나, 충돌을 일으키거나, 어떤 로그에도 나타나지 않습니다. 단순히 시스템의 일부가 존재하지 않게 되고, 보통 화가 난 사용자가 충분히 끈질긴 질문을 던져 그 구멍을 드러낼 때까지 아무도 알아차리지 못합니다. 그리고 이것은 필드 이름보다 훨씬 더 큰 문제의 상징입니다. 일반적인 RAG 프레임워크는 현재 텍스트(기사, 웹 페이지, 소설 단락)에 최적화되어 있으며, 테이블을 다루더라도 2등 시민으로 취급합니다. 하지만 이탈리아 기업 문서에는 테이블이 *자주* 포함되어 있습니다. 기술 카탈로그, 가격표, 제품 사양, 안전 데이터 시트, 주문 전표: 이러한 문서를 참조하는 사람에게 귀중한 부분은 테이블 부분입니다. 가장 먼저 고장나고 아무도 알아차리지 못하는 부분입니다.

교훈은 "필드 이름에 주의하라"가 아닙니다. 훨씬 더 까다롭습니다. 진지한 RAG에서는 테이블, 이미지, 영숫자 코드, 단락 제목, 각주 등 모든 유형의 콘텐츠에 대해 전용으로 설계, 테스트된 처리가 필요합니다. 그리고 작동 테스트는 "챗봇이 사소한 질문에 답변하는 것"이 아닙니다. 고장난 시스템도 충분한 부동 데이터가 있기 때문에 그럴듯한 것을 구축할 수 있으므로 이에 답변할 수 있습니다. 진정한 테스트는 "챗봇이 파이프라인의 모든 개별 부분을 건드려야 하는 질문에 답변하는 것"입니다. 구체적이고, 수치적이며, 검증 가능한 질문입니다. 정답이 하나만 있고, 시스템이 틀리면 즉시 알 수 있는 질문입니다.

이 테스트를 수행하지 않으면 RAG가 작동하는지 알 수 없습니다. 단순히 불평하지 않는다는 것만 알 수 있습니다. 그리고 "불평하지 않음"은 사람들이 의사 결정을 위해 사용할 시스템의 품질 기준으로는 매우 낮습니다.