리서치 리포트와 회의록이 쌓여도 필요한 근거를 찾기 어려운 순간이 있다. 처음 이 글을 쓸 때는 그 이유를 평평한 검색 구조 때문이라고 단정했다. 지금은 원인을 더 나눠볼 필요가 있다고 생각한다. 자료 접근 권한, 색인 여부, OCR과 표 추출, 질문의 조건이 맞지 않아도 같은 검색 실패를 겪을 수 있다.
Hyper-Extract는 텍스트를 개체와 관계 등 여러 구조로 추출하는 프로젝트다. 나는 아직 이 도구를 회사 자료로 실행하지 않았다. 공식 저장소와 문서를 검토하는 단계이며, 아래에서는 확인한 기능과 내가 제안하는 평가 방법을 구분한다. 기존 원문의 “Neo4j 글을 쓴 지 반년이 지났다”는 표현도 게시 날짜와 맞지 않아 제거했다. 관심을 가진 기간을 사용 경험처럼 늘려 설명하지 않는다.
형식과 추출 방법을 따로 고른다
Hyper-Extract를 볼 때는 결과를 어떤 구조로 보관할지와 어떤 방법으로 뽑아낼지를 구분하는 편이 이해하기 쉽다. 저장소는 Auto-Type, 추출 방법, 도메인 템플릿을 나눠 설명한다. 리스트, 그래프, 시간·공간 정보를 포함한 구조 등을 선택할 수 있고 CLI와 Python 사용 경로를 제공한다. 공식 저장소
이 구분을 리서치 문서에 적용해보면 첫 선택부터 달라진다. 보고서에 등장한 기관 목록만 필요하다면 중복을 정리한 목록으로 충분할 수 있다. 기관과 보고서의 인용 관계를 따라가려면 그래프가 후보가 된다. 같은 기업의 전망이 언제 바뀌었는지 확인하려면 시간과 출처를 함께 보존하는 설계가 필요하다.
2026년 9월 8일 확인한 README는 Document corpus를 포함해 9개 Auto-Type을 안내한다. 문서 사이트에는 9개라는 설명과 예전 8개 표가 함께 남아 있다. 기존 글의 8개 설명을 현재 기능의 고정 목록으로 유지하면 안 되는 이유다. 실제 설치할 버전의 코드와 템플릿을 함께 보고 제공하는 구조를 확인해야 한다. 공식 문서의 기능 안내
기능 수가 늘었다고 내가 가진 문서를 더 잘 처리하는지는 별도 문제다. 보고서 한 장에서 날짜와 단위를 놓치면 그래프를 여러 형태로 내보내도 오류를 고칠 수 없다. 먼저 정답으로 삼을 원문과 요구 필드를 정하고 출력 형식은 그 요구에 맞춰 선택한다.
다자간 사건은 하이퍼엣지와 사건 노드로 비교한다
다음은 설명을 위해 만든 가상 문장이다. “A브랜드는 2024년 3분기 한국 온라인 채널에서 B세그먼트 대상의 C캠페인을 진행했다.” 여기에는 브랜드, 시점, 지역, 채널, 대상, 캠페인이 함께 들어 있다. 내가 검색하려는 질문이 “A브랜드가 한 일”인지 “같은 시기에 같은 대상을 겨냥한 캠페인”인지에 따라 필요한 표현이 달라진다.
하이퍼그래프는 여러 개체를 하나의 관계로 묶는 표현을 제공한다. 다만 각 개체가 브랜드인지 대상인지 역할을 보존해야 한다. 같은 묶음 안에 이름을 넣는 것만으로 주체와 대상의 구분이 생기지는 않는다. 원문 위치와 추출 근거도 함께 연결해야 결과를 검증할 수 있다.
일반 그래프에서도 캠페인 실행을 사건 노드로 만들고 참여 개체를 연결할 수 있다. 원문에서 “이진 관계로 쪼개면 정보가 손실된다”라고 단정했던 부분은 수정한다. 사건의 식별자와 역할, 시점을 어떻게 설계하는지에 따라 정보를 보존할 수 있다. 하이퍼그래프의 표현 이점과 특정 검색 구현의 성능을 같은 것으로 취급하지 않는다.
| 표현 후보 | 가상 사건을 저장하는 방식 | 점검할 내용 |
|---|---|---|
| 구조화 레코드 | 한 행에 브랜드·캠페인·시점·지역·대상 저장 | 다른 문서의 동일 사건과 연결하는 방법 |
| 사건 노드가 있는 그래프 | 캠페인 실행 노드에 참여자와 역할 연결 | 관계 이름과 사건 ID의 일관성 |
| 하이퍼그래프 | 관련 개체를 사건 단위로 묶음 | 개체 역할·근거·질의 지원 보존 |
세 형식에 같은 가상 문장을 넣고 필요한 질문을 해보면 적합성을 비교하기 쉽다. 자료가 단순한데 복잡한 구조를 먼저 선택하면 검수와 유지 비용이 늘 수 있다. 관계 표현이 편하다는 판단과 실제 답을 빨리 찾았다는 결과를 각각 기록해야 한다.
경쟁 도구 비교표보다 내 자료의 검사표를 만든다
이전 글에는 GraphRAG, LightRAG, KG-Gen과 기능 지원 여부를 비교한 표를 넣었다. 개발 중인 프로젝트를 버전과 설정 없이 지원·미지원으로 표시하면 금방 부정확해진다. 공급자가 제시한 비교표를 독립적으로 검증한 성능 평가처럼 읽게 할 위험도 있다. 이번에는 내 자료에서 확인할 항목으로 바꿨다.
기관 별칭은 첫 검사 대상이다. 한글 이름과 영문 이름을 같은 기관으로 합칠 때 어떤 근거를 사용했는지 본다. 같은 약자를 쓰는 다른 기관을 합쳤다면 그 노드 주변 관계도 다시 검사한다. 수치에는 통화, 단위, 조사 시점, 추정치인지 확정치인지 붙어야 한다. 보고서에 2025년 전망과 2024년 실적이 함께 나올 때 어느 값이 최신이라는 한 단어로 덮어쓰지 않도록 한다.
도메인 템플릿은 요구 필드를 설계하는 출발점으로 사용한다. 금융이나 산업용이라는 이름만으로 회사 보고서에 맞는다고 판단하지 않는다. 템플릿이 선택한 개체, 관계, 식별자 규칙을 읽고 우리 질문에 필요한 정보를 버리지 않는지 확인한다. 템플릿 설계 안내에서 구조를 살핀 다음 작은 예시로 검사할 계획이다.
LLM이 판단하기 어려운 정보는 빈 값과 보류 사유로 남겨야 한다. 기준일이 없는 숫자에 문서 작성일을 자동으로 붙이면 의미가 달라질 수 있다. 다른 문서에서 본 기업 이름을 현재 문서의 누락 값에 채우는 동작도 추출과 추론을 섞는다. 보완 추론을 허용한다면 원문에서 추출한 값과 별도 필드로 구분한다.
공개 문서로 CLI와 갱신 경로를 시험한다
설치 안내의 시작 명령은 다음과 같다. uv가 준비된 환경에서 실행하는 예시이며 이 글을 쓰면서 설치·API 호출을 수행한 기록은 아니다. 설치 후에는 실제 패키지 버전과 사용한 설정을 기록하고 그 버전의 도움말을 확인한다.
uv tool install hyperextract
he --help
he parse --help
he feed --help
LLM과 임베딩 제공자 설정은 따로 확인한다. 추출 모델을 로컬로 골라도 임베딩이 외부 서비스면 문서의 일부를 외부로 보낼 수 있다. 키를 명령행에 직접 쓰면 셸 기록과 작업 로그에 남을 수 있으므로 조직에서 승인한 비밀정보 관리 방식을 사용한다. 문서에 보이는 최저 비용 예시를 내 PDF 처리 비용으로 옮겨 적지 않는다.
처음 입력할 파일은 재사용 권리를 확인한 공개 문서다. 핵심 사실 몇 개를 사람이 적고 추출 결과와 대조한다. 텍스트 한 개에서 정상 작동했다고 PDF 표와 스캔 이미지까지 같은 정확도를 기대하지 않는다. 확장 입력 형식에는 추가 구성 요소가 필요할 수 있으므로 설치 버전의 입력 지원과 옵션을 확인한다.
다음 시험은 동일 문서의 수정이다. 예시로 공개 연습 문서의 가상 수치 100을 110으로 바꾸고 같은 출처 식별자로 갱신해본다. 공식 문서는 같은 출처의 새 버전을 반영하고 기여 출처를 확인하는 흐름을 안내한다. 내 시험에서는 이전 값이 최신 답변에 섞이는지, 다른 문서에서 독립적으로 인용한 100까지 삭제되는지 확인해야 한다. 단순 교체와 독립 근거의 보존을 구분하는 검사다.
중복 파일을 다른 이름으로 넣는 시험도 필요하다. 같은 보고서를 두 번 넣었다고 근거의 수가 두 배로 늘었다고 판단하면 안 된다. 파일 해시, 원문 주소, 발행 기관과 문서 식별자를 이용해 같은 자료인지 확인할 정책을 둔다. 도구가 제공하는 출처 추적 기능과 조직의 문서 식별 정책을 함께 써야 한다.
검색 품질과 운영 비용을 같은 기록에 남긴다
첫 질문 묶음은 단일 문서의 사실, 문서 간 연결, 시점 변화, 답이 없는 질문으로 나눌 계획이다. 정답과 근거 위치를 모델 답변을 보기 전에 기록한다. 추출한 구조가 원문과 맞는지, 검색이 근거를 가져왔는지, 최종 답변이 그 근거를 정확히 사용했는지를 따로 판정한다.
저장소의 최근 설명에는 추출 없는 청크 기반 비교 방식도 등장한다. 같은 문서와 질문을 단순 검색 기준선에도 넣으면 구조화의 추가 비용을 판단하는 데 도움이 된다. 그래프 방식에만 더 좋은 모델이나 더 많은 근거 분량을 주었다면 그 차이를 표시한다. 가장 잘 나온 답만 공개하지 않고 실패한 질문과 수정 과정을 함께 남긴다.
비용에는 최초 추출, 질문, 갱신, 사람의 검수 시간을 포함한다. 관계 오류를 고치는 데 오래 걸리면 API 호출이 저렴해도 전체 업무가 빨라지지 않을 수 있다. Apache-2.0 라이선스의 소프트웨어를 이용한다는 것과 모델 API·호스팅·운영 비용이 없다는 것은 다른 이야기다. 라이선스는 저장소의 LICENSE에서 직접 확인할 수 있다.
지금 내 판단은 Hyper-Extract를 표현 구조와 출처 갱신 방식을 시험할 후보로 남겨두는 것이다. 구조화를 늘리기 전에 검색에 실패한 질문과 원문 상태를 확인한다. 실험에서 관계형 질문의 근거 확인이 쉬워지고 유지 비용을 설명할 수 있을 때 더 큰 자료군으로 넓힌다. 그 전까지는 설치 설명과 실제 운영 경험을 분리해서 기록한다.
참고자료
- Hyper-Extract 공식 저장소: 현재 README, 설치·갱신 흐름, 릴리스 변화.
- Hyper-Extract 공식 문서: 출력 구조와 CLI·SDK 안내. 일부 설명의 버전 차이에 주의한다.
- Hyper-Extract 템플릿 설계 안내: 필드와 관계를 설계할 때 확인할 원자료.
- Hyper-Extract LICENSE: Apache-2.0 라이선스 원문.