Claude Haiku 4.5에 RAG면 충분할까, 온톨로지의 경계

Claude Haiku 4.5가 충분히 똑똑하다면, 기업 지식 시스템도 RAG만 붙여 끝낼 수 있을까. 지금 중요한 질문은 모델 순위가 아니다. 검색, 관계 추론, 업무 실행 가운데 어디까지 만들 것인지가 투자 규모를 가른다.

Haiku 4.5는 작은 모델의 출발선을 높였다

Anthropic은 2025년 10월 Haiku 4.5를 공개하며 입력 100만 토큰당 1달러, 출력은 5달러로 책정했다. 회사가 공개한 SWE-bench Verified 점수는 73.3%로, 500개 문제를 50회씩 돌린 평균이자 bash와 파일 편집 도구를 쓴 조건에서 나온 값이다.

이 수치가 사내 문서 질의 성능을 곧바로 증명하지는 않는다. 그래도 저지연 상담, 하위 에이전트, 반복 검색처럼 호출량이 큰 자리에 강한 후보가 됐다. 커뮤니티에서도 좁게 정의한 작업은 Haiku 4.5로 충분하다는 의견이 많았다.

써본 사람들 사이에서는 계획은 큰 모델에 맡기고 탐색과 작은 수정은 Haiku에 나누는 방식도 호평받는다. 반면 긴 맥락과 복잡한 구현에서는 사소한 오판이 쌓여 검토 비용이 커진다는 반응도 있다.

모델 크기보다 작업 경계와 평가 방식이 먼저라는 얘기다.

문서 안에 답이 있으면 기본 RAG부터 검증한다

RAG는 질문과 가까운 문서 조각을 찾아 모델 입력에 붙인다. Lewis 연구진이 2020년 발표한 원형도 생성 모델과 외부 벡터 인덱스를 결합했다. 지식이 바뀔 때 모델 가중치를 다시 학습하지 않아도 된다는 점이 핵심이다.

구축 순서는 짧다.

제품 문서와 FAQ를 모아 제목과 문단 단위로 나눈 뒤 임베딩을 만든다. 벡터 검색에 키워드 검색을 섞고 재순위화한 다음 상위 조각과 출처를 Haiku 4.5에 전달한다. 입력은 사용자 질문이고 산출물은 근거 문서가 딸린 답변이다. 여기서 먼저 실제 질문 묶음을 만들어야 한다. 답을 포함한 조각이 검색됐는지, 답변이 근거와 맞는지, 지연과 비용이 허용 범위인지 잰다.

AWS의 2025년 비교도 RAG와 파인튜닝이 서로 다른 문제를 푼다고 설명한다. 최신 지식은 RAG가, 말투와 좁은 행동 패턴은 파인튜닝이 유리했다.

기본 RAG가 목표를 통과하면 온톨로지를 더할 이유는 약하다. 현장에서도 청킹, 혼합 검색, 재순위화를 다듬기 전에 그래프부터 얹지 말자는 의견이 많았다.

여러 문서를 잇는 질문에서 GraphRAG가 등장한다

문제는 답이 한 조각에 없을 때다. “전체 계약에서 반복되는 위험은 무엇인가”처럼 자료 전반을 묶는 질문은 유사도 검색만으로 빠뜨리기 쉽다. Microsoft Research의 GraphRAG 논문은 약 100만 토큰 규모 자료의 전체 맥락 질문에서 이 약점을 겨냥했다.

GraphRAG는 원문에서 엔티티, 관계, 주장을 추출한다. 이어 관계망의 군집을 찾아 단계별 커뮤니티 요약과 임베딩을 만든다. 현재 공식 구현은 결과를 기본적으로 Parquet 테이블과 벡터 저장소에 남긴다.

직접 시험하려면 텍스트 자료를 프로젝트 입력 폴더에 넣은 뒤 `graphrag init`으로 설정과 프롬프트를 만든다. `graphrag index`로 그래프와 요약을 생성한 뒤, 특정 인물 관계는 local search로 묻는다. 자료 전체의 주제를 물을 때는 global search를, 넓게 탐색한 뒤 세부로 좁힐 때는 DRIFT search를 쓴다.

대가는 인덱싱 비용과 유지보수다.

Microsoft 문서도 큰 작업 전 작은 자료와 저렴한 모델로 시험하라고 경고한다. 엔티티가 잘못 합쳐지거나 자료가 자주 바뀌면 재구축과 품질 점검이 늘어난다는 불만도 있다. 반복 평가에서 다중 문서 관계 질문이 계속 실패할 때만 넘어갈 근거가 생긴다.

GraphRAG를 온톨로지라고 부르면 설계가 흐려진다

W3C의 OWL 2는 사물, 집합, 관계를 표현하고 논리로 일관성을 검사하는 지식 표현 언어다. GraphRAG는 비정형 문서에서 LLM이 관계망을 추출하는 검색 파이프라인이다. 그래프를 쓴다는 공통점만으로 두 개념을 같은 것으로 볼 수 없다.

Palantir Ontology는 범위가 더 넓다. Foundry 문서에서 객체와 링크뿐 아니라 Action, 함수, 보안 정책까지 운영 모델에 넣는다. 주문과 설비를 연결해 보여주는 데서 멈추지 않고 권한을 확인한 뒤 주문 변경을 실제 시스템에 기록할 수 있다.

그래서 만드는 순서도 다르다. 원천 데이터를 연결해 고객·주문·설비 같은 객체와 속성을 정한다. 객체 사이 링크를 만든 다음, 승인·변경·알림 같은 Action과 권한을 붙인다. 산출물은 검색용 그래프가 아니라 사람과 에이전트가 함께 쓰는 읽기·쓰기 업무 계층이다.

“온톨로지”가 검색 그래프의 새 이름처럼 팔릴 때 경계가 사라진다. 한국 조직은 AX 병목을 먼저 풀어야 한다는 커뮤니티 의견도 이 지점을 가리킨다. 데이터 책임, 업무 규칙, 권한이 정리되지 않으면 거대한 모델링이 혼선을 확대할 수 있다.

필요한 것은 기술 등급표가 아니라 실패 질문이다

개인 개발자와 소규모 팀에는 세 단계가 현실적이다. Haiku 4.5와 기본 RAG로 대표 질문을 먼저 통과시킨 뒤 관계형 실패만 GraphRAG 실험군으로 분리한다. 실제 시스템을 바꾸는 기능이 생길 때 객체, Action, 권한을 모델링한다.

GPT 5.6과의 비교 관심도 있었지만 같은 자료와 평가셋으로 잰 결과가 없으면 선택 근거가 되지 않는다. 더 큰 모델도 검색되지 않은 사내 사실을 안정적으로 복원할 수는 없다.

좋은 아키텍처는 가장 많은 유행어를 담지 않는다. 반복해서 실패한 질문을 가장 작은 추가 구조로 해결한다. Haiku 4.5 시대의 온톨로지 논쟁은 기술의 우열보다, 검색을 넘어 어떤 결정을 실행할 것인지에서 갈린다.