비정형 및 반정형 데이터 수집

청구서 처리는 이미 해결된 문제여야 합니다. 문서가 도착하면 필드가 추출되고, 데이터가 기존 레코드에 대해 검증되고, 결과가 적절한 시스템으로 라우팅됩니다. 현실은 청구서 처리만으로도 기업들이 연간 수십억 달러를 수동 작업에 쏟아붓고 있으며, 이를 해결해야 할 자동화 프로젝트들은 끊임없이 망가집니다.

이유는 포맷 다양성입니다. 청구서는 PDF, 이메일 첨부 파일, 스캔 이미지, 스프레드시트 내보내기, 때로는 팩스로 도착합니다. 각 벤더는 다른 레이아웃을 사용합니다. 항목은 테이블, 자유 텍스트, 또는 둘의 조합으로 나타납니다. 세금 계산은 관할에 따라 다른 규칙을 따릅니다. 통화 형식도 다릅니다. 날짜 형식도 다릅니다. 같은 벤더도 사전 통지 없이 청구서 템플릿을 변경합니다.

기존 RPA는 템플릿 매칭으로 이를 처리합니다. 청구서 번호가 나타나는 좌표, 항목이 시작되는 위치, 합계가 있는 위치를 정의합니다. 단일 벤더의 현재 템플릿에는 작동합니다. 그런 다음 벤더가 시스템을 업데이트하고, 열을 옮기고, 헤더 행을 추가하고, PDF 생성기를 변경하면 봇은 완전히 실패하거나 누군가가 수동으로 발견할 때까지 다운스트림으로 전파되는 쓰레기 데이터를 추출합니다.

같은 패턴이 모든 비정형 데이터 워크플로에서 반복됩니다. 페이어가 양식 레이아웃을 변경하면 보험 EOB 처리가 망가집니다. 새로운 문서 유형이 프로세스에 추가되면 사전 승인 접수가 망가집니다. 누군가가 조금 다른 제목 형식을 사용하면 고객 이메일 파싱이 망가집니다. 이러한 자동화를 유지하는 비용은 종종 수동으로 작업하는 비용을 초과합니다.

Triggerfish의 해결 방법

Triggerfish는 위치 기반 필드 추출을 LLM 기반 문서 이해로 대체합니다. AI는 인간이 읽는 방식으로 문서를 읽습니다: 컨텍스트를 이해하고, 필드 간의 관계를 추론하고, 레이아웃 변경에 자동으로 적응합니다. 파이프라인 오케스트레이션을 위한 워크플로 엔진과 데이터 보안을 위한 분류 시스템과 결합하면, 세상이 변해도 망가지지 않는 수집 파이프라인이 만들어집니다.

LLM 기반 문서 파싱

문서가 Triggerfish 워크플로에 들어오면, LLM 서브에이전트는 특정 픽셀의 위치가 아닌 문서의 의미를 기반으로 구조화된 데이터를 추출합니다. 청구서 번호는 오른쪽 상단 모서리에 "Invoice #"이라는 라벨이 붙어 있든, 페이지 중앙에 "Factura No."라는 라벨이 붙어 있든, 텍스트 단락에 포함되어 있든 청구서 번호입니다. LLM은 "Net 30"이 지불 조건을 의미하고, "Qty"와 "Quantity"와 "Units"가 같은 의미이며, 설명, 요금, 금액 열이 있는 테이블은 열 순서에 관계없이 항목 목록임을 이해합니다.

이것은 "문서를 ChatGPT에 보내고 최선을 바라는" 일반적인 접근 방식이 아닙니다. 워크플로 정의는 LLM이 생성해야 하는 구조화된 출력, 적용될 검증 규칙, 추출 신뢰도가 낮을 때의 처리를 정확하게 지정합니다. 서브에이전트 작업 설명은 예상 스키마를 정의하고, 워크플로의 후속 단계는 추출된 데이터가 다운스트림 시스템에 들어가기 전에 비즈니스 규칙에 대해 검증합니다.

문서 검색을 위한 브라우저 자동화

많은 문서 수집 워크플로는 먼저 문서를 가져오는 것에서 시작합니다. 보험 EOB는 페이어 포털에 있습니다. 벤더 청구서는 공급업체 플랫폼에 있습니다. 정부 양식은 주 기관 웹사이트에 있습니다. 기존 자동화는 Selenium 스크립트나 API 호출을 사용하여 이러한 문서를 가져오고, 포털이 변경되면 그 스크립트들이 망가집니다.

Triggerfish의 브라우저 자동화는 LLM이 페이지 스냅샷을 읽어 탐색하는 CDP 제어 Chromium을 사용합니다. 에이전트는 DOM 트리가 아닌 인간처럼 페이지를 보고, 하드코딩된 CSS 셀렉터가 아닌 보이는 것을 기반으로 클릭, 타이핑, 스크롤합니다. 페이어 포털이 로그인 페이지를 재설계하면, 에이전트는 시각적 컨텍스트로 사용자 이름 필드, 비밀번호 필드, 제출 버튼을 식별할 수 있기 때문에 적응합니다. 탐색 메뉴가 변경되면, 에이전트는 문서 다운로드 섹션으로의 새 경로를 찾습니다.

이것이 완전히 신뢰할 수 있다는 의미는 아닙니다. CAPTCHA, 다단계 인증 흐름, JavaScript 의존성이 높은 포털은 여전히 문제를 일으킵니다. 하지만 실패 모드가 기존 스크립트와 근본적으로 다릅니다. CSS 셀렉터 매칭이 중단되면 Selenium 스크립트는 조용히 실패합니다. Triggerfish 에이전트는 무엇을 보았고, 무엇을 시도했고, 어디서 막혔는지를 보고하여 운영자가 개입하거나 워크플로를 조정할 수 있는 충분한 컨텍스트를 제공합니다.

분류 게이트 처리

문서는 다양한 감도 레벨을 가지며, 분류 시스템은 이를 자동으로 처리합니다. 가격 조건이 포함된 청구서는 CONFIDENTIAL일 수 있습니다. 공개 RFP 응답은 INTERNAL일 수 있습니다. PHI가 포함된 문서는 RESTRICTED입니다. LLM 서브에이전트가 문서를 읽고 데이터를 추출하면, POST_TOOL_RESPONSE 훅이 추출된 콘텐츠를 분류하고 세션 taint가 그에 따라 에스컬레이션됩니다.

이것은 다운스트림 라우팅에 중요합니다. CONFIDENTIAL로 분류된 추출된 청구서 데이터는 PUBLIC으로 분류된 Slack 채널로 전송될 수 없습니다. PHI가 포함된 보험 문서를 처리하는 워크플로는 추출된 데이터가 흐를 수 있는 위치를 자동으로 제한합니다. 쓰기 다운 방지 규칙은 모든 경계에서 이를 적용하며, LLM에게는 이를 재정의할 권한이 전혀 없습니다.

의료 및 금융 서비스에 특히 중요한 것은, 자동화된 문서 처리의 규정 준수 부담이 크게 줄어든다는 점입니다. 모든 파이프라인의 모든 단계에 커스텀 액세스 제어를 구축하는 대신, 분류 시스템이 균일하게 처리합니다. 감사자는 처리된 모든 문서, 추출된 데이터, 전송된 위치를 추적하고 부적절한 대상으로 데이터가 흐르지 않았음을 확인할 수 있습니다. 모두 모든 단계에서 자동으로 생성된 계보 레코드에서 확인 가능합니다.

자가 치유 포맷 적응

벤더가 청구서 템플릿을 변경하면, 기존 자동화는 누군가가 수동으로 추출 규칙을 업데이트할 때까지 망가진 채로 있습니다. Triggerfish에서는 LLM 서브에이전트가 다음 실행에서 적응합니다. 위치가 아닌 의미를 읽기 때문에 청구서 번호, 항목, 합계를 여전히 찾습니다. 추출이 성공하고, 데이터가 동일한 비즈니스 규칙에 대해 검증되고, 워크플로가 완료됩니다.

시간이 지나면서 에이전트는 크로스 세션 메모리를 사용하여 패턴을 학습할 수 있습니다. 벤더 A가 항상 다른 벤더에는 없는 재입고 수수료를 포함한다면, 에이전트는 이전 추출에서 그것을 기억하고 찾아야 한다는 것을 압니다. 특정 페이어의 EOB 형식이 항상 조정 코드를 특이한 위치에 배치한다면, 과거 성공적인 추출에 대한 에이전트의 메모리가 미래 추출을 더 신뢰할 수 있게 만듭니다.

포맷 변경이 충분히 중요하여 LLM의 추출 신뢰도가 워크플로에 정의된 임계값 아래로 떨어지면, 워크플로는 추측 대신 문서를 인간 검토 대기열로 라우팅합니다. 인간의 수정이 워크플로를 통해 피드백되고, 에이전트의 메모리는 미래 참조를 위해 새 패턴을 저장합니다. 아무도 추출 규칙을 다시 작성하지 않아도 시스템은 시간이 지남에 따라 더 스마트해집니다.

파이프라인 오케스트레이션

문서 수집은 단순히 "추출 후 저장"이 아닙니다. 완전한 파이프라인은 문서를 가져오고, 구조화된 데이터를 추출하고, 기존 레코드에 대해 검증하고, 다른 시스템의 데이터로 보강하고, 예외를 인간 검토로 라우팅하고, 검증된 데이터를 대상 시스템에 로드합니다. 워크플로 엔진은 이 모든 것을 단일 YAML 정의로 처리합니다.

의료 사전 승인 파이프라인은 이렇게 될 수 있습니다: 브라우저 자동화가 제공자 포털에서 팩스 이미지를 가져오고, LLM 서브에이전트가 환자 식별자와 시술 코드를 추출하고, HTTP 호출이 EHR에 대해 환자를 검증하고, 다른 서브에이전트가 임상 문서를 기반으로 승인이 의학적 필요성 기준을 충족하는지 평가하고, 결과는 자동 승인 또는 임상 검토 대기열로 라우팅됩니다. 모든 단계가 분류 추적됩니다. PHI의 모든 부분이 taint 태그가 붙습니다. 완전한 감사 추적이 자동으로 존재합니다.

실제 활용 사례

한 지역 의료 시스템이 각자의 양식 레이아웃을 사용하는 40개의 다른 제공자 사무실로부터 사전 승인 요청을 처리합니다. 일부는 팩스, 일부는 이메일, 일부는 포털에 업로드합니다. 기존 접근 방식은 포맷 다양성을 신뢰할 수 있게 처리할 수 있는 자동화 도구가 없어 8명의 팀이 각 요청을 수동으로 검토하고 입력해야 했습니다.

Triggerfish로 워크플로가 완전한 파이프라인을 처리합니다. 브라우저 자동화 또는 이메일 파싱으로 문서를 가져옵니다. LLM 서브에이전트가 포맷에 관계없이 구조화된 데이터를 추출합니다. 검증 단계가 추출된 데이터를 EHR과 처방집 데이터베이스에 대해 확인합니다. RESTRICTED의 분류 상한선이 PHI가 파이프라인 경계를 벗어나지 않도록 보장합니다. LLM이 높은 신뢰도로 파싱할 수 없는 문서는 인간 검토자에게 라우팅되지만, 에이전트의 메모리가 포맷 패턴 라이브러리를 구축함에 따라 그 볼륨은 줄어듭니다.

8명의 팀이 시스템이 플래그한 예외를 처리하는 2명이 되고, 자동화 추출에 대한 주기적인 품질 감사가 추가됩니다. 제공자 사무실의 포맷 변경은 자동으로 흡수됩니다. 새로운 양식 레이아웃은 첫 번째 만남에서 처리됩니다. 기존 자동화 예산의 대부분을 소비했던 유지 비용이 거의 0에 가깝게 줄어듭니다.