"우리 문서로 RAG를 붙이면 전문 AI가 되는 것 아닌가요." 요즘 가장 자주 보이는 착각입니다. PDF를 넣고, 벡터 검색을 붙이고, 모델이 그 문서를 인용하게 만들면 꽤 그럴듯합니다. 데모도 빠르게 나옵니다. 질문을 던지면 관련 문단이 붙고, 답변 끝에는 출처가 달립니다.
여기까지는 좋은 시작입니다. 다만 전문도메인 AI라고 부르기에는 아직 멉니다. 세무와 회계처럼 답 하나의 비용이 큰 영역에서는 검색된 문단만으로 충분하지 않습니다. 법률과 내부 규정도 같습니다. 문단을 제대로 찾았는지와 그 문단이 결론을 지지하는지는 다른 문제입니다. 근거가 맞아도 사실관계 적용이 틀릴 수 있고, 답은 맞아도 위험한 단정을 할 수 있습니다.
RAG는 전문 AI의 몸통이 아닙니다. 검색층입니다. 몸통은 그 바깥에 있습니다. 먼저 무엇을 맞혔다고 볼지 정하는 벤치마크. 결론을 뒤집는 근거를 골라내는 큐레이션. 가능한 결론을 좁히는 판정 구조, 반대편에서 공격하는 검증자, 계속 바뀌는 도메인을 따라가는 운영 리듬까지 붙어야 합니다.
RAG가 해주는 일과 못 해주는 일
RAG가 잘하는 일은 분명합니다. 긴 문서 전체를 프롬프트에 밀어 넣지 않고, 질문과 가까운 조각만 찾아 모델에게 줍니다. 비용을 줄이고, 출처를 붙일 수 있게 해줍니다. 한국어 기준서나 법령처럼 표현이 조금씩 다른 문서에서는 lexical 검색과 임베딩 검색을 섞은 hybrid 방식도 꽤 강합니다. "환매약정"이라는 질문이 본문에서는 "재매입약정"으로 적힌 경우, 의미 검색이 그 간극을 메웁니다.
문제는 그다음입니다. 검색은 후보 문단을 돌려줍니다. 그 문단이 결론을 결정하는 근거인지, 보조 설명인지, 범위 밖 문서인지 판단하지는 못합니다. 본문에 없는 키워드는 임베딩으로도 찾을 수 없습니다. 특정 시험 표현과 기준서 표현이 다르면 별도의 매핑 테이블이 필요합니다. 한국 상법처럼 코퍼스 밖에 있는 근거는 아무리 좋은 RAG도 못 가져옵니다.
검색 품질과 답변 품질도 분리해야 합니다. recall이 60에서 80으로 올랐다고 답변이 자동으로 안전해지지는 않습니다. round-trip은 줄어듭니다. 출처를 찾는 길도 열립니다. 산식과 사실관계 적용은 여전히 판정 시스템의 몫. 인용이 그 결론에 맞는지도 따로 봐야 합니다.
- 문서를 chunk로 나누고 검색한다
- 관련 문단을 답변에 붙인다
- 출처가 있으면 신뢰할 만해 보인다
- 검색 실패와 판정 실패를 한 문제로 본다
- 무엇을 맞혔다고 볼지 먼저 정의한다
- 결론을 뒤집는 결정적 근거를 따로 큐레이션한다
- 가능한 결론을 제한하고 이유를 기록한다
- 검색 품질과 답변 품질을 따로 잰다
먼저 벤치마크를 만들어야 합니다
전문도메인 AI에서 가장 먼저 필요한 것은 검색기가 아니라 시험지입니다. 이 시스템이 무엇을 잘해야 하는지 정의하지 않으면 개선도 없습니다. 내부 골드셋에서 98%를 맞혔다고 해도, 그 골드셋이 무엇을 재는지 모르면 제품 신뢰로 이어지지 않습니다.
좋은 도메인 벤치마크는 두 층으로 나뉩니다. public split은 예시와 튜토리얼용입니다. 오염되어도 괜찮습니다. private holdout은 점수 발표용입니다. 정답을 숨겨야 모델이 문제를 외워서 맞히는 일을 막을 수 있습니다. 케이스마다 expected ruling과 decisive source를 박습니다. category, difficulty, 기준일도 따로 둡니다. 그래야 점수 1점의 의미가 생깁니다.
여기서 중요한 필드는 decisive source입니다. 답을 결정짓는 조문과 판례. 해석례와 기준서 문단. 전문도메인에서는 근거가 많다고 좋은 게 아닙니다. 결론을 뒤집는 근거가 무엇인지 알아야 합니다. RAG가 문단 열 개를 찾아와도, 그중 결정적 근거가 빠지면 시스템은 실패한 것입니다.
판정 구조는 검색보다 좁아야 합니다
전문도메인 AI는 자유롭게 말하게 두면 안 됩니다. 가능한 결론의 목록을 먼저 좁혀야 합니다. 과세, 비과세, 부분과세. 인식, 제거, 재분류. 적법, 위법, 보완 필요. 도메인마다 이름은 다르지만 원리는 같습니다. 결론 공간을 열거형으로 제한합니다.
그다음 reasoner가 핀과 사실관계를 놓고 그 제한된 공간 안에서 판단합니다. 이때 RAG는 자유 검색이 아니라 결정적 근거의 주입 경로가 됩니다. 모델이 스스로 찾게 두는 것이 아닙니다. 시스템이 "이 이슈는 이 근거를 반드시 보라"고 밀어 넣습니다.
마지막에는 adversary가 필요합니다. reasoner가 낸 결론을 반대편에서 공격하는 역할입니다. 누락된 사실관계가 있는지 확인합니다. 다른 조문이 우선하는지도 봅니다. 판례 하나가 결론을 뒤집는지도 따집니다. self-eval로는 이 벽을 넘기 어렵습니다. 같은 모델이 자기 답을 검토하면 처음 잡은 전제를 계속 붙잡는 경우가 많습니다.
- 01Benchmark
- 02Decisive sources
- 03Retrieval
- 04Reasoner
- 05Adversary
- 06Synthesis
도메인 랩이 먼저고 제품은 나중입니다
여러 전문 앱을 동시에 만들다 보면 제품 repo가 실험실이 되는 일. 세무 AI. 회계 기준서 Q&A. 계약서 검토. 내부 규정 챗봇. 겉으로는 전부 같은 RAG처럼 보입니다. 실제로는 다른 벤치마크와 다른 판정 규칙을 요구합니다. 검증되지 않은 실험은 upstream lab에 둬야 합니다.
랩에서는 모델과 하드웨어 한계를 먼저 잽니다. 어떤 임베더가 한국어 문서에서 버티는지 확인합니다. hybrid 검색이 recall을 얼마나 올리는지도 따로 봅니다. reranker 필요 여부와 증분 ingest 안정성은 실험으로 가릅니다. 민감한 도메인 데이터는 외부 서비스로 보내지 않는다는 경계도 여기서 정합니다. 검증된 파이프라인만 제품 repo로 분리합니다.
이 순서를 지키면 제품 코드는 가벼워집니다. 제품은 검증된 조합을 가져다 쓰고, 랩은 다음 조합을 계속 시험합니다. 실패한 실험이 사용자 화면에 섞이지 않습니다. 전문도메인에서는 이 분리가 신뢰의 일부입니다.
운영도 제품의 일부입니다. 문서는 바뀝니다. 법령은 개정되고, 기준서는 새 문단이 생기고, 내부 규정은 파일명이 바뀝니다. 전체 코퍼스를 매일 다시 임베딩하는 방식은 곧 막힙니다. 파일의 mtime과 size를 추적하고, 바뀐 문서만 다시 넣고, 삭제된 문서는 인덱스에서 지워야 합니다. RAG가 데모가 아니라 서비스가 되는 지점입니다.
RAG는 필요하지만 충분하지 않습니다
RAG 없이 전문도메인 AI를 만들기는 어렵습니다. 문서 기반 근거 제시가 필요하고, full-context는 비용과 지연에서 곧 한계에 부딪힙니다. RAG는 당연히 필요합니다. 하지만 "필요하다"와 "충분하다"는 다릅니다.
전문도메인 AI의 질문은 "무슨 문단을 찾았나"에서 끝나지 않습니다. 그 문단이 결론을 결정하는가. 가능한 결론 목록 안에서 어디에 속하는가. 반대편 주장은 무엇인가. 모델이 인용한 근거를 실제로 조회했는가. 새 모델이 들어왔을 때 bare 대비 하네스 delta가 유지되는가. 이 질문들이 붙어야 합니다.
결국 전문도메인 AI는 검색창이 아닙니다. 판정 시스템입니다. 검색은 그 시스템의 한 층입니다. 신뢰는 검색 결과의 개수에서 나오지 않습니다. 무엇을 맞혔다고 볼지 정한 뒤, 그 기준으로 계속 재는 구조에서 나옵니다.
- domain-llm-benchmark-design
- llm-adversary-harness-pattern
- rag-harness-architecture-pattern
- rag-hybrid-search-recall-improvement-pattern
- rag-incremental-ingest-pattern
- domain-ai-backend-lab-pattern
