그라운딩은 학습 문제로 잘못 이해되고 있습니다. 팀은 소스 문서를 선별하고, 올바르게 청킹하고, 출시 전에 검색이 작동하는지 확인하는 데 시간을 씁니다. 그리고 배포 후 다음 작업으로 넘어갑니다.
이는 잘못된 사고 모델입니다. 그라운딩은 런타임 속성입니다. 배포 시점뿐만 아니라 모든 추론 호출에서 유지되어야 합니다. 소스 데이터가 변경되었는데 검색 레이어가 그 변경을 반영하지 않는 순간, 시스템은 그라운딩이 해제됩니다. 그리고 누군가 발견할 때까지 오래된 사실을 자신 있게 계속 답변합니다.
대부분의 팀은 이를 발견하지 못합니다. 발견할 수 있는 메커니즘이 없기 때문입니다.
런타임에서 그라운딩이 실제로 의미하는 것
그라운딩된 AI 시스템은 매 실행마다 세 가지를 수행합니다:
- 현재의 권위 있는 소스에서 컨텍스트를 검색합니다
- 검색된 컨텍스트를 조건으로 응답을 생성합니다
- 검색 결과가 빈약할 때 검색된 컨텍스트를 파라메트릭 메모리로 대체하지 않습니다
세 번째 항목이 대부분의 시스템이 조용히 실패하는 지점입니다. 검색이 약한 결과를 반환하면, 많은 시스템이 모델이 이미 알고 있는 것으로 폴백합니다. 이 폴백은 사용자에게 보이지 않습니다. 응답은 자신 있어 보입니다. 그럴듯하기까지 합니다. 하지만 더 이상 그라운딩된 것이 아닙니다. 모델이 몇 달 또는 몇 년 전의 학습 데이터에서 추측하는 것입니다.
이것은 모델 품질 문제가 아닙니다. 아키텍처 문제입니다. 시스템이 추론 시점에 자체 그라운딩 상태를 검증하도록 설계된 적이 없는 것입니다.
배포 시점 그라운딩 함정
구체적인 실패 시나리오를 살펴보겠습니다.
팀이 검색 증강 시스템을 구축합니다. 출시 전에 그라운딩 검사를 실행합니다. 알려진 질문 20개로 검색 레이어를 쿼리하고 답변이 소스 문서와 일치하는지 확인합니다. 모두 통과합니다. 배포합니다.
6주 후, 소스 문서가 변경되었습니다. 가격이 업데이트되었습니다. 제품이 deprecated되었습니다. 정책이 개정되었습니다. 검색 인덱스는 같은 일정으로 갱신되지 않았습니다. 출시 시점의 그라운딩 검사는 여전히 녹색을 표시합니다. 배포 시점에 한 번 실행되었고, 다시 실행되도록 예약된 적이 없기 때문입니다.
시스템은 deprecated된 제품에 대한 질문에 계속 답변합니다. 이전 가격을 인용합니다. 이전 정책을 인용합니다. 알림은 발생하지 않습니다. 로그 항목도 플래그를 세우지 않습니다. 사용자는 잘못된 답변을 받고, 팀은 아무런 신호도 받지 못합니다.
이것은 드문 엣지 케이스가 아닙니다. 그라운딩을 설정 단계가 아닌 지속적인 계약으로 취급하지 않을 때의 기본 결과입니다.
그라운딩 카나리아 패턴
해결책은 예약된 프로브, 즉 그라운딩 카나리아입니다. 추론 파이프라인과 독립적으로 실행되며, 정해진 간격으로 알려진 사실을 라이브 검색에 대해 테스트합니다.
구축 방법은 다음과 같습니다.
1단계: 팩트 픽스처 세트 정의
검증 가능하고, 구체적이며, 시간이 지남에 따라 변경될 가능성이 있는 사실 15~30개를 선택합니다. 이것이 카나리아입니다. 좋은 후보:
- 가격 페이지의 특정 가격 또는 티어 한도
- 명명된 기능과 현재 상태 (활성, deprecated, 베타)
- 버전 또는 발효일이 있는 정책 세부 사항
- 조직 변경에 따라 바뀌는 연락처 또는 소유권 필드
구조적으로 안정적인 사실(회사 설립 연도, 제품 카테고리)은 피하십시오. 소스 데이터가 드리프트하면 함께 드리프트할 사실이 필요합니다.
2단계: 예상 검색 어설션 작성
각 사실에 대해 검색 어설션을 작성합니다. 보낼 쿼리, 검색될 것으로 예상되는 문서 또는 청크, 검색된 컨텍스트에 반드시 나타나야 하는 특정 문자열 또는 값입니다.
예시:
- 쿼리:
"Pro 플랜의 가격은 얼마입니까?" - 예상 소스:
pricing.md,Pro Plan섹션 - 예상 값:
"$149/month"
이것은 생성 테스트가 아닙니다. 모델이 무엇을 말하는지 테스트하는 것이 아닙니다. 검색 레이어가 무엇을 반환하는지 테스트하는 것입니다. 두 관심사를 분리하십시오.
3단계: 프로브 예약 및 드리프트 임계값 설정
소스 데이터 업데이트 빈도에 맞는 일정으로 프로브를 실행합니다. 지식 베이스가 매일 갱신된다면 카나리아도 매일 실행합니다. 주간으로 갱신된다면 주간으로 실행하되, 수동 인덱스 업데이트 후 1시간 이내에도 실행합니다.
배포 전에 드리프트 임계값을 설정합니다. 합리적인 시작점: 어설션의 10% 이상 실패 시 알림. 20개 사실 중 2개 실패입니다. 도메인의 중요도에 따라 조정하십시오. 가격 또는 컴플라이언스 콘텐츠의 경우 더 낮게 설정하십시오. 실패 1건도 중단을 정당화할 수 있습니다.
임계값이 초과되면 알림은 명확해야 합니다. 로그 항목이 아닙니다. 검색 인덱스 담당자에게 몇 분 내에 도달하는 알림이어야 합니다.
4단계: 카나리아 실패를 인시던트로 취급
그라운딩 실패는 유지보수 작업이 아닙니다. 시스템이 사용자에게 잘못된 정보를 적극적으로 제공하고 있다는 의미입니다. 서비스 중단과 동일한 긴급도로 취급하십시오. 소유권을 할당하십시오. 사후 분석을 요구하십시오. 평균 감지 시간과 평균 해결 시간을 추적하십시오.
인시던트로 취급하지 않으면 임계값은 장식이 됩니다.
실제로 어떻게 보이는가
20개 팩트 픽스처 세트에서 이 패턴을 실행하는 팀이 가격 업데이트 11일 후 검색 드리프트를 발견했습니다. 소스 문서가 변경된 후 인덱스가 갱신되지 않았습니다. 카나리아가 없었다면 시스템은 11일 동안 질문한 모든 사용자에게 잘못된 가격을 인용했을 것입니다. 로그 항목도 없고 불만도 없이. 대부분의 사용자는 올바른 가격이 무엇인지 모르기 때문입니다.
카나리아가 이를 발견했습니다. 인덱스가 갱신되었습니다. 사후 분석에서 문서 업데이트 워크플로우에 갱신 트리거가 추가되었습니다. 동일한 실패는 재발하지 않았습니다.
이것이 운영 중인 그라운딩 계약의 모습입니다. 우아하지 않습니다. 예약된 작업, 픽스처 파일, 임계값, 온콜 로테이션입니다. 시스템을 정직하게 유지하는 지루한 인프라입니다.
검색 증강 시스템을 구축하거나 운영하고 있는데 그라운딩 카나리아가 실행되고 있지 않다면, 지금 시스템이 그라운딩되어 있는지 알 수 없습니다. 출시 시점에 그라운딩되어 있었다는 것만 알 뿐입니다.
DK1.AI의 AI Brand Presence는 그라운딩 검증을 일회성 구성이 아닌 지속적인 운영 레이어로 포함합니다. 특정 검색 아키텍처에서 이것이 어떻게 보이는지 이해하고 싶다면, 다음 단계는 직접 대화입니다.