스캔본 매뉴얼과 사진 첨부 티켓: 지식 그래프가 22분짜리 지원 검색을 끝내는 방법

핵심 요약

• 12,000문서 규모의 지원 라이브러리 중 70%는 텍스트 레이어가 없습니다 — 460명 규모 펌프 제조사 기준 약 126,000페이지가 키워드 검색에서도, 텍스트 전용 벡터 인덱스에서도 보이지 않습니다.
• Perplexity의 pplx-embed-v2-late가 MADQA에서 92.4%의 정답률에 도달했습니다 — 2026년 10월 7일 공개된 이 모델군은 OCR 파이프라인 없이 렌더링된 PDF 페이지를 직접 검색하며, 18,000페이지가 넘는 실환경 PDF 800건 위에서 에이전트가 500개의 질문에 답했습니다.
• 0.6B 쿼리 인코더는 9B 모델로 구축한 인덱스를 질의할 수 있습니다 — 공유 임베딩 공간이 고비용의 오프라인 페이지 색인과 저비용 라이브 질의를 짝지으며, 0.6B 모델은 MIT 라이선스의 594M 파라미터입니다.
• LinkedIn의 GraphRAG 프로덕션 배포는 검색 정확도를 77.6% 개선했습니다 — 지식 그래프의 구조적 에지는 벡터 인덱스가 볼 수 없는 것입니다.
• 페이지 인용 규칙이 실패 모드를 바꿉니다 — 문서 페이지, 품번, 시리얼 범위 없이는 어떤 답도 에이전트 밖으로 나가지 않으며, 검증되지 않은 것은 고객에게 보내는 대신 사람에게 에스컬레이션합니다.

중견 펌프·상수도 설비 제조사가 매주 받는 950건의 티켓 중 300건은 제품 불만이 아니라 문서 질문입니다. 1998년에 제작된 시리얼 43-11092의 SP-200에 어떤 임펠러가 맞는지, O&M 매뉴얼의 토크 표를 어떤 서비스 브리튼이 대체하는지, 2014년 개정판이 어떤 가스켓 재질을 지정하는지 — 각각 명판 사진이나 매뉴얼 페이지 스캔본을 첨부해 도착합니다. 이 질문들 뒤에 있는 기술 라이브러리는 12,000문서, 약 180,000페이지를 보유하고 그중 약 70%는 1970년대부터 이어진 텍스트 레이어 없는 스캔 종이며, Zendesk의 검색 인덱스는 그중 한 페이지도 읽지 못합니다.

비용은 두 개의 대기열에 나타납니다. 사내에서는 기술 지원 담당 6명이 문서 질문 하나에 평균 22분의 수동 검색을 수행합니다 — PDF를 하나씩 열며 스마트폰 사진을 펌프 곡선과 육안으로 대조하는 작업입니다. 사외에서는 딜러와 판매점이 지원 메일함에 이메일을 넣고 회답까지 중앙값 14시간을 기다립니다. 시니어 기술자 2명이 에스컬레이션된 문서 질문의 55%를 맡아 남들의 검색 노동으로 주당 약 19시간을 흡수합니다. 그리고 최악의 실패는 느린 쪽이 아닙니다. 잘못 읽은 회로도가 틀린 카트리지를 출하시키고 재입고 사이클과 두 번째 방문을 부르며, 이 회사의 작년 한 해에 운송과 재입고 처리만으로 약 3만 8천 달러를 지우게 했습니다.

본 글은 세 층짜리 해법 — 문서 라이브러리 위의 페이지 단위 지식 그래프, OCR 단계 없이 렌더링된 PDF 페이지를 검색하는 늦은-상호작용 임베딩, 그리고 정확한 페이지를 첨부해 답하는 에이전트 흐름 — 을 각 층의 원차 소스인 Perplexity의 2026년 10월 7일 발표와 LinkedIn의 GraphRAG 프로덕션 배포에 고정시키며 지도합니다.

문제: 모두가 검색을 접어버린 라이브러리

종이 시절이 있는 모든 제조사가 이런 라이브러리를 갖고 있습니다. 최근 5년치 매뉴얼은 디지털 원생입니다. 그 이전의 모든 것은 스캐너를 통해 들어왔습니다. 펌프 곡선, 배선도, 분해 조립도, 치수표. 글자가 판독되는 페이지가 있는가 하면 구멍과 접힌 선과 여백의 손글씨 메모가 찍힌 열화된 스캔본도 많습니다. 검색 가능한 30%만이 쉬운 부분이고 나머지 70%는 파일명으로만 라벨된 이미지의 벽입니다. 그렇기 때문에 키워드 검색도 텍스트 전용 벡터 인덱스도 똑같은 방식으로 실패합니다. 둘 다 존재하지 않는 텍스트를 필요로 하기 때문입니다.

자명한 처방 — "아카이브에 OCR를 돌리면 된다" — 는 언제나의 죽음을 맞았습니다. OCR 오류는 열화된 스캔 위에서 겹겹이 쌓이고, 비즈니스 가치가 있는 바로 그 지점에 떨어집니다. 펌프 곡선의 축은 판독 불가능한 문자가 되고, 치수표는 어긋나고, 부품 목록의 열은 서로 붙습니다. 이것이 Perplexity 팀이 "비싸고 손실이 크다"고 부르는, 먼저 해석하고 나중에 검색하는 파이프라인이며 — 검색이 페이지를 보기 전에 "레이아웃, 표 구조, 그림, 공간 관계"를 버려버립니다. 이 라이브러리의 OCR 재구축은 여섯 자릿수 견적이 나왔고 두 번째 자금 지원은 받지 못했습니다.

벡터 검색 파일럿은 다른 이유로 실패했습니다. 임베딩된 텍스트는 정확한 "모양"의 펌프 곡선을 잘못된 개정판에 대해, 고객 설비와 맞지 않는 매뉴얼의 가스켓 사양을 돌려주었습니다. 벡터 인덱스 안에는 어떤 임펠러가 다른 임펠러를 대체하는지, 어떤 토크 표가 특정 시리얼 범위에서 철회되었는지를 알아보는 장치가 없습니다 — 그럴듯하고, 확신에 차 잘못된, 바로 틀린 부품을 출하시키는 답입니다. 어시스턴트는 보류되었고 두 명의 시니어 기술자가 사실상의 시스템 오브 레코드로 남았습니다. 이 사이트의 이전 지원 지식 그래프 문서는 소프트웨어 문서에서 같은 실패 모드를 보여줍니다. 스캔된 하드웨어 라이브러리에서는 그릇된 임시 조치가 아니라 그릇된 페이지를 고릅니다.

에이전트 오케스트레이션 해법: 페이지 아래의 그래프, 페이지 위의 임베딩

작동하는 패턴은 각 층에게 자기가 잘하는 일만 맡깁니다.

레이어 1 — 페이지 단위 지식 그래프. 모든 문서가 노드가 되고 문서 안의 모든 페이지도 노드가 되며, 렌더링 이미지는 한 번만 저장합니다. 부품, 펌프 기종, 시리얼 범위, 개정판이 노드이고, 에지는 질문에 답하는 사실입니다. 매뉴얼 4412는 모델 SP-200을 문서화한다; 118쪽에 임펠러 표가 있다; 임펠러 88-114는 시리얼 43-0850 초과 범위에서 88-114A를 대체한다; 브리튼 91-07은 40쪽의 토크 표를 철회한다; 그리고 NetSuite 주문 이력으로부터 — 시리얼 43-11092는 1998년 특정 딜러에게 출하되었고 그 소유주는 서비스 계약을 보유하고 있다. 이중 어느 것도 페이지가 텍스트일 것을 요구하지 않습니다. 그래프는 회사가 이미 유지하는 카탈로그, 주문 기록, 개정 카드로부터 만듭니다.

레이어 2 — 렌더링된 페이지 위의 페이지 단위 임베딩. 스캔된 70%는 OCR를 필요로 하지 않습니다. 2026년 10월 7일 공개된 Perplexity의 pplx-embed-v2-late 계열은 "OCR이나 파싱된 텍스트를 요구하지 않으면서 렌더링된 PDF 페이지를 직접 검색하는 text-to-image 검색을 처리합니다". 두 크기 — 0.6B와 9B, MIT 라이선스로 Hugging Face 게시 — 는 토큰마다 하나의 128차원 벡터를 만들고 ColBERT식 MaxSim으로 점수를 매겨 펌프 질문에 필요한 디테일을 살립니다: "임펠러", "SP-200", 그려진 축 지름이 같은 렌더링 페이지의 서로 다른 영역에 매칭됩니다. MADQA — 실환경 이기종 PDF 800건, 18,000페이지 이상, 일반 지식으로만으로는 답할 수 없도록 쓰인 500개의 문제 — 에서 9B 모델은 92.4%, 0.6B 모델은 90.1%를 정답 처리합니다. 시각 문서 벤치마크 ViDoRe(v3)에서는 0.6B 모델이 활성 파라미터가 자신의 5배인 모델들과 맞먹습니다. 두 모델은 하나의 임베딩 공간을 공유하므로 라이브러리는 9B 모델로 한 번만 색인되고, 티켓의 라이브 질의는 0.6B 인코더를 통과합니다 — 매뉴얼이 고객 현장의 기밀을 실을 때 중요한, 벤더가 아닌 제조사가 통제하는 하드웨어 위에서 온전히 구동될 수 있다는 디테일입니다.

레이어 3 — 단단어가 아닌 인용으로 끝나는 에이전트 흐름. Model Context Protocol(MCP)을 말하는 커넥터 모듈이 Zendesk(티켓, 요청자, 첨부), NetSuite(주문, 시리얼 이력, 보증 상태), 그래프 질의 도구를 감쌉니다. 흐름은 이렇습니다. 에이전트가 티켓과 사진 첨부를 읽고, 임베딩에 후보 렌더링 페이지를 물은 뒤, 그래프를 걸어 후보 페이지가 주장하는 것을 확인합니다 — 맞는 개정판, 맞는 시리얼 범위, 맞는 대체 관계 — 그리고 실제 PDF 페이지를 첨부하고, 품번을 텍스트로 밝히고, 근거를 명시("브리튼 91-07에 따르면 페이지 표는 40쪽")하여 답합니다. 거버넌스 규칙은 한 줄이고 그 한 줄이 하중을 견딥니다. 페이지 인용이 없으면 발신 없음 — 티켓은 사람에게 에스컬레이션합니다. 구매 계열의 질문은 대체 부품에 대해 라이브 가용성을 홀드하는 RFQ 엔진으로 넘어가 가격이 붙은 견적으로 해결을 닫습니다. 딜러 쪽 요청은 스코프가 지정된 A2A 에이전트로 위임되며 검색과 그래프의 모든 단계는 모듈 코드 표준 패턴으로 기록됩니다. 구현 가이드는 그래프 자체의 구축을 다룹니다. 이 글은 운용 패턴이지 모든 아카이브에 대한 보증이 아닙니다.

시니어 기술자 2명은 다른 고도에서 루프에 남습니다. 안전과 관련된 모든 것을 승인하고, 플래그된 저신뢰 큐를 검토하고, 그래프가 근거를 세울 수 없는 것을 처리합니다. 그들은 라이브러리의 색인으로 남지 않습니다.

결과

같은 티켓, 두 가지 해법 — 오늘의 수동 검색 대 정확한 페이지를 첨부해 답하는 에이전트 오케스트레이션 흐름:

이 회사의 규모에서 이 형태의 도입이 실현할 때의 대표 목표와, 패턴이 의지하는 벤치마크 근거:

지표	이전	에이전트 오케스트레이션 목표
문서 질문 첫 응답	14시간(딜러 이메일 중앙값)	2분 이하, 페이지 인용 + 렌더링 첨부
사내 처리 중앙값	22분 수동 검색	3분 — 기술자가 첨부된 페이지 검증
시니어 기술자 에스컬레이션 부담	문서 질문의 55%(주 약 19시간)	문서 질문의 20% 미만
품번 오출하	분기당 9건(연 3만 8천 달러)	파일럿 분기 1건
검색 가능 페이지	54,000(텍스트 레이어가 있는 30%)	약 180,000, 렌더링 페이지 그대로

패턴을 지탱하는 근거: 실환경 스캔 PDF 위의 에이전트 QA에서 OCR 파이프라인 없이 92.4% 정확도, 그래프 구조 검색의 LinkedIn에서 측정된 77.6% 검색 정확도 개선, 그리고 지원 지식 그래프 도입이 소프트웨어 쪽에서 실증한 프로필(해결 28시간을 7로, 에스컬레이션 45%를 18%). 정직한 범위 표시: MADQA는 벤치마크이지 모든 아카이브에 대한 약속이 아닙니다 — 그래서 인용 규칙과 사람의 검토가 루프에 남습니다.

더 깊은 변화는 라이브러리의 부패가 멈춘다는 점입니다. 어떤 문서가 무엇을 대체하고, 어떤 부품이 무엇의 대용이고, 어떤 설비가 어떤 개정판을 받았는지가 이제 은퇴를 앞둔 두 사람의 머리가 아니라 그래프에 기록됩니다.

관련 읽기

• 고객 지원 해결 시간 7시간: 지식 그래프가 티켓 처리 시간을 75% 단축하는 방법 — 소프트웨어 쪽 자매 유스 케이스
• GraphRAG 구현 가이드: 텍스트 문서에서 프로덕션 지식 그래프 검색까지 — 페이지 단위 그래프를 구축하는 5단계 파이프라인
• 고객 지원을 위한 GraphRAG: 지식 그래프가 데이터베이스가 답할 수 없는 질문에 답하는 방법 — 구조화 검색이 비용을 감수할 가치가 있는 때

---

12,000문서, 그중 70%가 스캔본인 펌프 제조사는 문서 검색마다 22분을 잃고, 어떤 시스템도 펌프 곡선을 읽지 못하기 때문에 가끔 틀린 부품을 출하시킵니다. 페이지 단위 지식 그래프와 OCR 없이 렌더링 페이지를 검색하는 임베딩, 그리고 정확한 페이지를 첨부해 답하는 에이전트 — 페이지 인용 없으면 발신 없음으로 닫힌 — 이 라이브러리를 다시 답할 수 있게 만들고, RFQ 엔진은 "어떤 부품이 맞는가"를 가격이 붙고 홀드된 견적으로 바꿉니다.

범위가 확정된 구축을 요청하십시오

1주일 디스커버리. 시스템 인벤토리, 워크플로 맵, 확정 범위를 받게 됩니다 — 저희와 함께하든 아니든.