평균 200페이지가량의 특허 분쟁대응 보고서를 비전문가가 읽을 수 있는 1–2페이지로 줄여야 했습니다. 문제는 긴 문서만이 아니었습니다. 20건의 샘플은 20페이지부터 600페이지 이상까지 길이가 달랐고, 여러 특허법인의 양식과 영어·일본어·중국어가 한데 섞여 있었습니다.
Context length 극복 방법론
기업 요구사항에 따라 별도 GPU 인스턴스를 사용할 수 없었고, 지식재산정보원 지원사업 보고서를 다루기 위해 공공기관 클라우드 보안 인증 중급 이상을 충족하는 네이버 API만 사용해야 했습니다. 따라서 오픈소스 모델은 선택지에서 제외하고 당시 조건을 충족한 HyperCLOVA X를 사용했습니다.
당시 HyperCLOVA X의 최대 토큰 한도는 8,192였지만 보고서 원문은 평균 10만 자가 넘었습니다. 한 번에 넣을 수 없으므로 장문 요약의 두 방식을 먼저 비교했습니다.
| 방식 | 동작 | 한계 |
|---|---|---|
| Map Reduce | 청크별로 따로 요약한 뒤 결합 | 청크 사이 연결이 끊기고 출력 형식이 들쭉날쭉 |
| Refine | 직전 청크 요약을 다음 입력에 함께 전달 | 요약문이 누적되며 뒤로 갈수록 토큰 공간 부족 |
Refine은 앞의 맥락을 이어가기 좋지만 문서 뒤쪽에 쓸 토큰 공간이 계속 줄어, 분량이 긴 보고서는 후반부를 요약할 컨텍스트가 부족해졌습니다. 반대로 Map Reduce는 긴 문서를 안정적으로 나눌 수 있는 대신, 청크 사이 전환이 불연속적이고 요약 결과가 파편화됐습니다. 저는 Map Reduce로 청크별 요약을 만든 뒤 전체 요약문의 연결과 형식을 다시 쓰는 단계를 추가했습니다.
PDF를 텍스트로 변환하고 길이에 따라 1차·2차 요약을 실행한 다음, 문제특허·대응전략·국가별 특이사항이 남도록 최종 요약문을 재작성하는 흐름입니다.
벡터 문서 검색
요약 모듈을 완성한 뒤, 기업에서 임베딩 기반 관련 문서 검색을 추가로 요청했습니다. 최종 요약문에서 LLM으로 키워드를 추출해 기존 TF-IDF 결과와 비교하고, 문서 검색도 TF-IDF와 벡터 임베딩 방식으로 각각 구현했습니다. 정확한 단어가 겹치는 문서는 기존 방식으로, 동의어와 유사어가 포함된 문서는 벡터 검색으로 찾을 수 있도록 구성했습니다.
결과
문제특허, 대응전략, 국가별 특이사항을 포함한 요약문과 문서 검색 기능을 구현했습니다. 결과를 기업 데이터베이스에 적재하고 소스 코드를 전달하면서 프로젝트를 마쳤습니다.