Improve contract search accuracy with auto-generated filters in Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

계약 분석 시스템 AIDA는 메타데이터 기반 암시적 필터와 정책 기반 명시적 필터를 결합해 의미 검색의 정확도, 접근 통제, 답변의 출처 추적성을 높인다.

📌 핵심 요약

• AIDA는 비정형 계약서를 검색 가능한 정보로 변환하고, 사용자가 대규모 계약 저장소에 자연어로 질문할 수 있도록 지원한다.
• 법률 문서는 문맥 의존성이 높고 의미 검색이 반환할 수 있는 청크 수에도 한계가 있어, 필터링이 부정확하면 핵심 조항이 누락되거나 관련 없는 계약이 포함될 수 있다.
• 계약서는 당사자, 효력 발생일, 종료일, 관할권 등의 메타데이터와 함께 수집되며, 의미 단위로 분할된 뒤 임베딩으로 변환되어 벡터 데이터베이스에 저장된다.
• 암시적 필터는 의미 검색 전에 메타데이터 조건으로 검색 범위를 자동 축소하고, 명시적 필터는 지역·기간·기밀 등급과 같은 조직의 고정 정책을 애플리케이션 계층에서 강제한다.
• 검색된 계약 청크와 메타데이터는 질문과 함께 LLM 프롬프트에 제공되며, 최종 답변에는 출처가 연결되지만 실제 업무에 사용할 계약 해석은 자격을 갖춘 법률 전문가가 검토해야 한다.

🧩 주요 포인트

1. 수백 개의 후보 청크 중 의미 검색이 반환하는 상위 결과는 최대 100개로 제한될 수 있다 → 계약 유형과 준거법을 먼저 필터링해야 핵심 갱신 조항의 누락 가능성을 줄일 수 있다.
2. 암시적 필터는 질문과 관련된 메타데이터 조건으로 후보군을 좁히고 명시적 필터는 사용자 입력과 무관한 정책 경계를 적용한다 → 검색 적합성과 권한·규정 준수를 서로 다른 계층에서 함께 확보한다.
3. 필터링은 검색 대상을 제한하지만 문서 수준 메타데이터를 LLM에 자동 전달하지는 않는다 → 정확한 답변을 위해서는 검색 제약뿐 아니라 청크와 프롬프트에 충분한 계약 문맥을 제공해야 한다.

🧠 상세 정리

1. 대규모 계약 검색이 가진 구조적 문제

기업은 계약서에서 권리, 갱신 조건, 지리적 제한, 규정 준수 의무를 확인해 중요한 업무 결정을 내려야 한다. 특히 여러 관할권에 걸쳐 수천 건의 계약을 관리하는 엔터테인먼트·미디어 분야에서는 이러한 검토가 상당 부분 수작업으로 이루어져 시간과 비용이 많이 들고 확장하기 어렵다. AIDA는 비정형 계약서를 검색하고 활용할 수 있는 정보로 바꾸며, 사용자가 대규모 저장소를 대상으로 자연어 질문을 할 수 있게 한다. 그러나 법률 문서는 개별 조항의 의미가 계약 유형과 관할권, 다른 조항에 좌우되므로 의미 검색만으로는 충분하지 않으며, 검색할 문서와 청크를 정밀하게 통제하고 문서 수준의 문맥을 함께 제공해야 한다.

2. 계약 수집과 검색 기반 구성

처리 과정은 계약서를 구조화된 메타데이터 파일과 함께 Amazon Bedrock Knowledge Bases에 동기화하는 단계에서 시작한다. 메타데이터에는 계약 당사자, 효력 발생일, 종료일, 관할권 등 이후 검색 범위를 제한하는 데 사용할 핵심 속성이 포함된다. 계약 본문은 검색에 적합한 의미 단위로 분할되며, 각 청크는 필요한 문맥을 유지하면서도 효율적으로 처리할 수 있을 만큼 간결하게 구성된다. 처리된 청크는 임베딩으로 변환되어 Amazon OpenSearch Service나 Amazon S3 Vectors 같은 벡터 저장소에 보관되고, 이를 통해 단순 키워드 일치가 아닌 개념적 유사성 검색이 가능해진다. 이 단계에서 함께 수집된 메타데이터는 일반적인 RAG와 달리 의미 검색 전에 후보 문서를 걸러 내는 암시적 필터의 핵심 기반이 된다.

3. 사용자 질문부터 답변 생성까지의 흐름

사용자가 질문을 제출하면 AIDA는 먼저 Amazon Bedrock Guardrails를 사용해 프롬프트 주입과 데이터 유출 위험을 완화하고, 질문을 임베딩으로 변환한다. 이후 암시적 필터와 명시적 필터를 적용해 검색할 계약 집합을 제한한 다음, 필터링된 범위 안에서 일반적으로 코사인 유사도를 이용해 관련 청크를 찾는다. 검색된 청크는 계약 메타데이터와 함께 원래 질문에 결합되어 LLM에 전달할 증강 프롬프트를 구성한다. LLM은 자체 학습 데이터에만 의존하지 않고 실제 계약서에서 검색된 내용에 근거해 답변을 생성하며, Guardrails는 콘텐츠 필터링과 개인정보 보호, 프롬프트 안전 통제에도 사용된다. 최종 답변은 Retrieve API를 통해 제공되고 특정 원문 문서로 연결되므로, 사용자는 답변의 근거를 확인할 수 있다.

4. 법률 RAG에서 후보 청크가 만드는 정확도 한계

원문은 ‘캘리포니아법이 적용되는 만료된 라이선스 계약과 그 갱신 방식’을 묻는 사례를 통해 검색 범위 조정의 필요성을 설명한다. 이 질문과 의미상 관련된 텍스트 청크는 여러 문서에 걸쳐 수백 개가 될 수 있지만, Amazon Bedrock의 의미 검색은 관련도가 높은 상위 k개 후보만 반환하며 그 최댓값은 100개다. 반환 대상에서 제외된 청크에도 중요한 조건이나 갱신 문맥이 포함될 수 있어, LLM의 답변이 불완전하거나 핵심 내용을 놓칠 가능성이 생긴다. 계약 유형과 캘리포니아 준거법을 제대로 제한하지 않으면 서비스 계약, 비밀유지계약 또는 다른 주법이 적용되는 계약의 만료·갱신 문구까지 결과에 섞일 수 있다. 따라서 의미 유사도를 계산하기 전에 메타데이터로 후보군을 좁히는 과정은 질문에 맞는 문맥을 LLM에 충분히 제공하기 위한 핵심 조정 수단이다.

5. 암시적 필터의 2단계 검색 방식

암시적 필터는 사용자가 매번 별도의 필터 표현식을 작성하지 않아도 문서 메타데이터를 이용해 검색 결과를 자동으로 제한하는 기능이다. 각 지식 기반 문서에는 최대 10KB의 사용자 정의 메타데이터 파일을 제공할 수 있으며, 효력 발생일, 문서 유형, 계약 당사자와 같은 속성을 담을 수 있다. 첫 번째 단계에서는 의미 유사도 검색을 실행하기 전에 질문과 관련된 메타데이터 조건을 적용해 벡터 저장소의 대상 문서 집합을 축소한다. 두 번째 단계에서는 축소된 문서 집합 안에서만 벡터 유사도 검색을 수행하므로, 관련 없는 계약에서 발생하는 잡음을 줄이고 질문의 업무 조건을 충족하는 청크가 상위 결과에 포함될 가능성을 높인다.

6. 명시적 필터가 강제하는 조직 정책

명시적 필터는 사용자의 질문 해석에 맡기지 않고 애플리케이션 계층에서 일관되게 적용되는 고정 제약이다. 이를 통해 검색 결과가 지역별 규정, 특정 기간, 기밀 또는 분류 등급과 같은 업무 정책과 규정 준수 요건을 항상 따르도록 할 수 있다. 예를 들어 지역 제약은 유럽 사용자가 유럽연합 관련 계약만 조회하도록 제한할 수 있고, 시간 제약은 최근 2년 동안 유효한 문서만 반환하도록 구성할 수 있으며, 민감도 제약은 필요한 기밀 등급이 지정된 문서만 허용할 수 있다. 원문 예시는 메타데이터의 지역 목록에 독일이 포함되고 기밀 등급이 공개인 문서만 검색하도록 두 조건을 AND로 결합하며, 이처럼 명시적 필터는 모든 질문이 중요한 접근 경계를 지키도록 하는 안전장치로 작동한다.

7. 필터링 이후에도 필요한 메타데이터 문맥

암시적 필터와 명시적 필터는 후보 청크의 범위를 좁히지만, 필터에 사용된 구조화된 문서 정보를 LLM에 자동으로 전달하지는 않는다. 메타데이터는 계약 원문 바깥에서 문서를 설명하는 구조화된 속성이며, 문서 수집과 색인 처리 후에 생성된다. 계약 유형, 준거법, 효력·만료 시점, 당사자 같은 값은 어떤 문서가 검색 대상인지 결정하는 데 쓰일 뿐 아니라, 검색된 조항을 올바른 계약 수준의 문맥에서 이해하는 데에도 필요하다. 따라서 검색 단계의 후보 제한과 생성 단계의 문맥 제공은 구분되어야 하며, 원문이 설명한 프롬프트 증강 과정처럼 관련 계약 청크와 메타데이터가 실제로 LLM 입력에 포함되도록 구성해야 한다.

8. 보안·추적성과 법률 검토의 필요성

구성 요소 사이의 문서 업로드, 임베딩 모델 API 호출, 벡터 데이터베이스 질의, 클라이언트 응답 전송에는 HTTPS와 TLS 1.2 이상의 전송 암호화가 사용된다. 벡터 저장소는 저장 데이터 암호화를 활성화하도록 구성하며, 지식 기반 접근과 모델 호출은 AWS IAM 정책으로 통제되고 Amazon CloudWatch 로깅을 통해 감사 기록을 유지한다. AIDA의 애플리케이션 계층에서는 프로젝트 범위 역할에 기반한 권한 통제를 적용해 각 사용자가 수행할 수 있는 작업을 제한한다. 답변에 특정 출처 문서를 연결하는 방식은 사용자가 결과를 검증할 수 있게 하고, LLM 답변의 환각 위험을 줄이는 데 도움을 준다. 다만 이러한 검색 개선은 법률적 판단을 대체하지 않으며, AI가 생성한 계약 해석을 업무 결정에 사용하기 전에는 자격을 갖춘 법률 전문가가 반드시 검토해야 한다.

🧾 핵심 주장 / 시사점

• 법률 검색의 정확도는 임베딩 모델의 유사도 계산만이 아니라, 검색 전에 계약 유형·관할권·기간을 얼마나 정확하게 제한하는지에 크게 좌우된다.
• 암시적 필터와 명시적 필터는 각각 질문 관련성 확보와 조직 정책 강제라는 서로 다른 역할을 담당하므로, 한 종류의 필터만으로 두 목적을 대체할 수 없다.
• 출처가 연결된 답변과 접근 제어는 신뢰성을 높이지만, 시스템은 법률 전문가를 대신하는 자동 판정 수단이 아니라 검토 범위를 줄여 주는 의사결정 지원 도구로 사용해야 한다.

✅ 액션 아이템

• AIDA에서 암시적 필터를 계약 유형·준거법 기반 메타데이터로 우선 적용해 검색 적합도를 높인다.
• 임베딩으로 변환한 계약 청크를 벡터 데이터베이스에 넣을 때 당사자·효력 발생일·종료일·관할권 메타데이터를 점검한다.
• 상위 100개 계약 청크와 메타데이터를 함께 LLM 프롬프트에 넣어 답변의 정확도와 출처 연결성을 보완한다.

❓ 열린 질문

• 암시적 필터에서 계약 유형·관할권 메타데이터가 부족하면 핵심 갱신 조항 누락 위험을 어떤 지표로 완화할 것인가?
• 명시적 필터가 지역·기간·기밀 등급 정책을 애플리케이션 계층에서 강제할 때 접근 통제와 검색 적합성을 어떻게 조율할 수 있는가?
• 문서 수준 메타데이터가 LLM 프롬프트에 전달되지 않을 때 자격을 갖춘 법률 전문가 검토에 맞춰 어떤 계약 문맥을 추가해야 하나?