없는 필드를 지어내는 RAG, 구조로 틀어막는다

검색 증강 생성(RAG)을 규제 산업에 적용한 팀들은 같은 벽에 부딪힌다. 맥락은 제대로 검색해 왔는데, 정작 대규모 언어 모델(LLM)이 데이터 모델에 존재하지도 않는 필드·임곗값·식별자를 그럴듯하게 지어내는 것이다. 소비자 앱에서는 성가신 정도지만, 은행 여신 심사나 의료 코호트 산정, 컴플라이언스 질의에서는 그 자체로 거버넌스 사고다. 최근 공개된 속성 지식 RAG(AK-RAG, Attribute Knowledge RAG) 패턴은 이 문제를 구조로 틀어막는다.

무슨 일인가 / 배경

표준 RAG는 애초에 이런 환각을 막도록 설계되지 않았다. 문서 조각을 검색해 LLM에 맥락으로 넘기면, LLM은 그 맥락에서 추론한 필드명·식별자·임곗값을 자유롭게 생성한다. 검색해 온 내용이 실제 데이터 카탈로그에 존재한다는 보장이 어디에도 없다는 것이 구조적 결함이다. '제공된 필드만 쓰라'는 프롬프트 지시나 사후 출력 검증은 언 발에 오줌 누기일 뿐, 근본 문제인 '검색 단위'가 틀렸다는 것이 이 패턴의 진단이다.

핵심 짚어보기

AK-RAG의 해법은 검색 단위를 바꾸는 것이다. 문서를 임베딩하는 대신, 거버넌스를 거친 속성 카탈로그를 개별 지식 객체로 색인한다. 문서 한 쪽당 하나가 아니라 속성 하나당 임베딩 하나다. 이렇게 하면 LLM의 역할은 필드명 생성이 아니라 '자연어 구절 추출과 명확화 대화'로 좁혀지고, 최종 출력에는 색인에 실재하는 속성 ID만 등장할 수 있다.

파이프라인은 둘로 나뉜다. 속성 색인을 만드는 적재 파이프라인은 엑셀·CSV·API로 관리되는 메타데이터를 계약 검증·정규화(동의어 분리, 범위·임곗값 파싱, 타입 정리)를 거쳐 '속성 하나=문서 하나'인 NDJSON으로 바꾼 뒤 임베딩·색인한다. 질의 파이프라인은 자연어를 거버넌스된 DSL로 옮긴다. 색인은 날짜로 버전을 매기고 원자적 별칭 교체로 승격해, 새 메타데이터 배포가 운영 색인을 어중간하게 갱신하는 사고를 막는다.

1인기업 실전 적용 포인트

• 사내 데이터에 LLM을 붙일 때, 문서 전체가 아니라 '컬럼·속성 목록'을 먼저 색인 대상으로 삼아라. 모델이 있지도 않은 지표를 만들어내는 사고를 원천 차단한다.
• 속성마다 동의어·정의·단위·거버넌스 정보를 담은 카탈로그(NDJSON 한 줄)를 만들어 두면, 개발 단계에서는 BM25 같은 로컬 검색만으로도 클러스터 없이 시작할 수 있다.
• 색인을 날짜 버전으로 관리하고 별칭만 바꿔 교체하면, 운영 중 데이터가 반쯤 갱신돼 답변이 오염되는 사고를 피할 수 있다.
• 고객 데이터·의료·금융처럼 '틀린 필드=사고'인 영역일수록 이 패턴의 값어치가 크다.

전망 / 주의점

AK-RAG는 만능이 아니다. 속성 카탈로그 자체를 정성껏 관리해야 하고, 임베딩용 텍스트를 손으로 다듬는 등 초기 설계 비용이 든다. 그러나 환각을 '프롬프트로 달래는' 접근에서 '구조로 불가능하게 만드는' 접근으로 넘어가는 흐름은 규제 산업 AI에서 거스르기 어렵다. 1인기업이라도 자기 데이터로 신뢰할 수 있는 질의 봇을 만들려 한다면, 검색 단위를 다시 보는 이 발상은 곱씹어 볼 만하다.

출처: SuperML.dev (https://superml.dev/attribute-knowledge-rag-pattern-llm-governed-attributes)