회사 보고서를 검색할 때 원하는 답은 짧다. 작년 시장 규모의 추정치, 그 수치가 들어 있는 페이지, 추정에 사용한 가정. 그런데 비슷한 제목의 보고서가 여러 개면 검색기는 과거 버전이나 다른 지역의 자료를 가져올 수 있다. 답변 문장이 매끄러워도 회의 자료에 옮기기 어렵다.
내가 만들고 싶은 것은 산업별 리포트를 다시 찾아 읽을 수 있는 지식 베이스다. 특정 서비스의 검색 실패를 모델 성능 하나로 설명하거나 GraphRAG 도입 효과를 측정했다는 글은 아니다. 여기서는 보고서 검색의 실패 원인을 구분하고 작은 실험으로 다음 투자를 결정하는 설계안을 정리한다. 예시 문서와 평가 수치는 실제 회사 자료나 실측 결과가 아닌 실험용 제안이다.
검색 기술을 고르기 전에 정답 페이지를 고른다
첫 작업은 보고서 열 개와 질문 스무 개를 고르는 것이다. 질문에는 단순 사실 확인, 표 읽기, 서로 다른 문서 비교, 자료 전체의 흐름 파악을 섞는다. 질문을 만든 사람이 정답 문서·페이지와 판단 근거를 기록한다. 검색 시스템이 만든 답을 다시 정답으로 사용하면 평가 자체가 틀린 결과를 따라갈 수 있다.
예를 들어 시장 규모 질문에는 국가, 기준 연도, 통화, 단위를 적는다. 같은 1조 원이라도 생산액인지 소비 지출인지에 따라 의미가 다르다. 검색 결과가 올바른 문서를 찾았더라도 주석에서 제외한 항목을 놓쳤다면 답변 판독 실패로 기록한다. 문서를 찾지 못했을 때만 검색 설정을 바꾸고, 표나 각주를 오독했을 때는 추출·생성 단계를 살핀다.
| 질문 예시 | 사람이 준비할 정답 | 먼저 확인할 실패 지점 |
|---|---|---|
| 2025년 국내 시장 추정치는? | 문서 버전, 페이지, 단위 | 연도 필터와 청크 검색 |
| 표에서 두 회사의 점유율 차이는? | 행·열 머리글, 값, 각주 | 표 추출과 이미지 판독 |
| 상반기와 하반기 전망의 가정이 어떻게 달라졌나? | 양쪽 문서의 근거 구간 | 여러 문서 검색과 비교 |
| 보고서 묶음에서 반복한 위험은? | 사람이 분류한 주제와 근거 | 자료 전체를 포괄하는 검색 |
접근 권한도 이 단계에서 정한다. 개인 실험에는 공개 보고서나 반출 승인을 받은 자료를 사용한다. 회사의 OneDrive·SharePoint 문서를 개인 벡터 DB나 외부 모델에 옮기면 별도의 보안·계약 문제가 생긴다. 원본을 읽을 수 있었던 직원만 검색 결과도 읽게 하는 권한 필터가 필요하다. 검색 품질을 높이려고 접근 범위를 넓혀서는 안 된다.
텍스트 검색에서는 청크보다 문서 경계를 먼저 보존한다
Text RAG의 기본 흐름은 텍스트 추출, 검색 단위 분할, 관련 구간 검색, 근거를 이용한 답변 작성이다. PyMuPDF 같은 파서와 벡터 저장소를 조합할 수 있지만 도구를 선택하기 전에 추출한 본문을 직접 읽어봐야 한다. 두 단 편집 PDF에서 문장을 엇갈리게 읽거나 페이지 머리말을 문장 사이에 끼워 넣으면 이후 단계에서도 오류를 다루게 된다.
청크에는 document_id, 버전, 페이지, 제목 경로, 공개 범위를 함께 저장하는 방식이 좋다. 문서 제목만 저장하면 같은 이름의 수정본을 구별하기 어렵다. 표를 분할할 때는 열 머리글과 단위를 반복해 붙인다. 비용을 줄이려고 숫자 행만 남기면 모델은 값이 매출인지 성장률인지 알 근거를 잃는다.
512토큰과 64토큰 겹침은 시험할 후보일 수 있어도 한국어 보고서의 정답 설정은 아니다. 문단 경계 방식과 제목 경계 방식을 같은 질문 세트에서 비교하고, 정답 근거가 중간에서 잘리는 빈도를 확인한다. 한글·영문을 섞어 묻는 질문도 별도로 둔다. 임베딩 모델이 다국어를 지원한다는 설명만으로 사내 약어와 산업 용어의 검색 품질을 보장할 수는 없다.
벡터 검색 결과와 키워드 검색 결과를 함께 비교할 가치도 있다. 계약 번호나 제품 코드처럼 정확한 문자열이 중요한 질문은 의미 유사도만으로 순위를 정하기 어렵다. 검색기 두 개의 원점수 범위가 다르면 그대로 더하지 않는다. 순위 기반 결합을 후보로 시험하고, 정답 근거가 상위 결과에 들어오는지를 본다. 답변이 길어진 정도로 검색 품질을 평가하지 않는다.
이 단계에서 정답 페이지를 안정적으로 찾는다면 여기서 운영을 시작해도 된다. 문서가 많다는 이유만으로 그래프를 도입할 필요는 없다. 저장 용량과 검색 실패 원인은 별도로 측정해야 한다.
페이지 이미지 검색은 표와 도표를 확인하는 보조 경로다
텍스트 파서가 표의 행·열 관계를 자주 훼손하면 페이지 이미지 검색을 추가할 후보가 생긴다. 기존 원고에서는 이를 PixelRAG라는 한 단계로 묶었지만 특정 제품이나 표준 하나를 가리키는 표현처럼 사용하지 않기로 했다. 핵심은 문서 페이지를 이미지로 검색하고 해당 페이지를 다시 판독하는 방식이다.
ColPali 연구진은 문서 페이지 이미지에서 다중 벡터를 만들고 텍스트 질문과 매칭하는 접근을 제안했다. 일반 이미지의 전역 특징을 비교하는 방식과 문서 검색용 다중 벡터 방식은 구분해야 한다. 논문 벤치마크의 결과를 한국어 산업 보고서에 그대로 적용한 성능 수치로 읽어서도 안 된다. ColPali 논문
실험에서는 텍스트 검색과 이미지 검색에 같은 질문을 준다. 정답 페이지를 찾은 비율과 찾은 뒤 값을 정확히 읽은 비율을 나눠 적는다. 이미지 경로가 올바른 표를 가져왔어도 작은 각주, 잘린 범례, 흐린 스캔 때문에 오답을 낼 수 있다. 페이지 이미지를 모델에 넣으면 표 문제가 사라진다는 식으로 설명할 수 없는 이유다.
예를 들어 표에서 12.4를 읽었다면 단위와 분모를 함께 출력하게 한다. 전년 대비 퍼센트인지 퍼센트포인트인지까지 근거와 대조한다. 답변 옆에는 독자가 확인할 원본 페이지를 제공한다. 표만 잘라 전달하는 경우에도 표 제목과 각주를 함께 보존해야 한다.
이미지를 저장하면 저장량과 추론 입력량이 늘어난다. 모든 페이지를 두 경로로 처리하기보다 텍스트 추출이 부실한 문서군부터 시험하는 편을 택하겠다. 이미지 경로를 추가하고도 수작업 검수 시간이 줄지 않는다면 해상도나 파서를 고치는 쪽이 우선이다.
GraphRAG는 자료를 묶어서 묻는 질문으로 평가한다
여러 보고서에서 반복한 위험 요인을 비교하거나 특정 조직과 관련된 주장을 모으는 질문에는 그래프 기반 검색을 시험할 이유가 있다. Microsoft GraphRAG의 Local Search는 추출한 그래프와 원문 청크를 함께 활용하고 Global Search는 커뮤니티 보고서를 활용해 자료 전체를 다루는 질문에 답한다. 공식 문서는 기본 벡터 검색도 비교용으로 제공한다. GraphRAG 검색 방식
도입 전에는 회사 이름의 표기부터 맞춰본다. 법인명, 약칭, 브랜드명을 다른 조직으로 추출하면 관계가 흩어진다. 같은 이름의 국내 법인과 해외 본사를 합쳐도 문제가 생긴다. 사람 검토를 거친 별칭 표와 원문 근거를 남겨야 관계를 수정할 수 있다.
관계 종류도 구별한다. A가 B를 언급했다는 사실과 A가 B에 투자했다는 사실은 다르다. 두 기업이 한 문단에 등장했다고 거래 관계로 묶으면 그럴듯한 오답을 만든다. 추출한 관계에 근거 문장과 페이지를 연결하고, 사람이 확인한 관계와 모델이 추정한 관계를 구분해 보관한다.
나는 단순 사실 질문의 정확도를 유지하면서 문서 간 비교 질문에서 검수 시간을 줄이는지를 통과 기준으로 삼겠다. 그래프의 노드가 많거나 시각화가 화려한지는 성과 지표에 넣지 않는다. 정답 근거의 누락, 엉뚱한 조직 통합, 인덱스 생성 비용을 함께 기록한다. 문서가 늘면 GraphRAG가 필수가 된다는 예측보다 이 기록이 다음 선택에 도움이 된다.
GraphDB는 저장·갱신·질의 요구가 있을 때 선택한다
기존 원고의 “GraphRAG는 그래프를 메모리에만 두므로 다시 구축해야 한다”는 설명은 정정한다. Microsoft의 기본 파이프라인은 그래프 관련 테이블을 디스크의 Parquet 파일로 저장한다. 영구 보존 자체를 위해 Neo4j가 반드시 필요한 것은 아니다. GraphRAG 출력 형식
GraphDB를 검토할 이유는 관계를 여러 서비스가 조회하거나 특정 경로를 반복 질의하고 운영자가 관계를 수정해야 할 때다. 그때는 문서와 조직을 어떤 ID로 식별할지, 보고서가 삭제되면 어떤 관계를 지울지, 수정본의 근거를 어떻게 교체할지 정한다. 새 문서를 넣는 일보다 삭제·정정 후의 일관성을 확인하는 작업이 어렵다.
시작 스키마는 작은 편이 좋다. Document와 Organization, 그리고 근거가 확인된 MENTIONS 정도로 시작하는 설계를 제안한다. 투자·의존·영향 관계는 구분 기준과 정답 사례를 만든 뒤 추가한다. 두 보고서에 같은 기업이 등장했다고 서로 영향을 줬다고 저장하지 않는다.
운영 평가에는 인덱스 재생성 후 복구, 이전 문서 버전 제거, 접근 권한 회수 시험을 포함한다. 권한이 사라진 문서의 본문을 숨기더라도 요약이나 관계를 남겨두면 정보가 새어 나갈 수 있다. 원본, 청크, 이미지, 추출 관계까지 같은 문서 ID로 추적할 수 있어야 삭제 범위를 확인한다.
내 첫 실험의 결과물은 네 기술을 연결한 대형 시스템보다 질문별 실패 기록이어야 한다. 텍스트로 충분한 질문, 이미지가 필요한 질문, 여러 문서의 관계를 찾아야 하는 질문을 구분하면 필요한 투자 순서를 정할 수 있다. 구축 기간도 그때 추정한다. 자료량과 권한 요구를 모른 채 10주 안에 완성한다고 약속할 근거는 없다.