Legora, Turbopuffer로 AI 법률 검색 확장

핵심 기능에는 계약 검토, 문서 작성 및 광범위한 법률 연구가 포함되며, 다양한 법률 워크플로우를 간소화하는 중앙 집중식 작업 공간 역할을 합니다.

Jacob은 "우리는 법률 업무를 위한 협업 AI 플랫폼입니다. 즉, 로펌과 사내 법무팀이 고객입니다."라고 말했습니다.

프로젝트 검색은 단일 작업 또는 프로젝트와 관련된 특정 문서를 분석하는 데 중점을 두며, 프로젝트 크기는 수십 개에서 수백만 개의 문서에 이릅니다. 이와 대조적으로 법률 연구는 방대한 데이터 세트에서 법률, 사례 및 규범에 대한 광범위한 탐색을 포함합니다.

Jacob은 "그래서 Lor에서는 두 가지 유형의 검색을 합니다. 프로젝트 검색과 법률 연구입니다."라고 설명했습니다.

이러한 모놀리식 설정은 모든 클라이언트 테넌트가 단일 블롭 스토리지 및 검색 인스턴스를 공유한다는 것을 의미했습니다. 처음에는 구현하기 간단했지만, 회사가 확장됨에 따라 이 접근 방식은 한계를 드러냈습니다.

Legora가 성장함에 따라 엄격한 지리적 데이터 상주 요구 사항에 직면했으며, 미국, EU, 호주와 같은 특정 지역 내에서 데이터 처리가 필요했습니다. 이러한 규정 준수 요구로 인해 회사는 전체 인프라 스택을 여러 지역에 걸쳐 복제해야 했고, 여러 ElasticSearch 클러스터 관리로 인해 운영 오버헤드가 크게 증가했습니다.

Jacob은 "그래서 기본적으로 음... 여기 확장 그래프가 있습니다. 여러 ElasticSearch로 이동해야 했습니다."라고 언급했습니다.

엔터프라이즈 클라이언트는 엄격한 보안 표준을 부과했으며, 주로 모든 데이터에 대한 완전한 물리적 격리를 요구했습니다. Legora는 휴지 상태 데이터에 대한 고객 관리 암호화 키를 구현하여 클라이언트가 필요에 따라 암호화 키에 대한 액세스를 취소하여 제어권을 유지할 수 있도록 함으로써 이를 해결했습니다. 이는 높은 수준의 데이터 보안 및 클라이언트 자율성을 보장합니다.

Jacob은 "가장 중요한 것은 모든 데이터에 대한 완전한 물리적 격리를 요구한다는 것입니다."라고 말했습니다.

Legora는 시스템을 단순화하고 기존 OOLTP 워크로드 설정을 활용하기 위해 핵심 검색 인프라를 ElasticSearch에서 Postgres로 전환했습니다. 이 전략적 움직임은 벡터 임베딩 및 디스크 근사 최근접 이웃(ANN) 검색을 위한 PGvector와 전체 텍스트 검색 기능을 위한 TSvector를 사용하는 것을 포함했습니다. 이러한 통합은 운영을 간소화하고 시스템 관리 용이성을 향상시키는 것을 목표로 했습니다.

Jacob은 "그래서 ElasticSearch에서 Postgress로 옮겼는데, 여러분 중 많은 분들이 왜 벡터를 Postgress에 넣겠느냐고 생각하실 것입니다."라고 언급했습니다.

NVMe SSD 캐시는 휘발성 메모리로 처리되어 표준 디스크 암호화 규칙을 우회하고, 특정 워크로드에 대한 디스크 캐시를 비활성화하면 메모리 전용 캐싱으로 높은 성능을 유지하는 데 도움이 됩니다.

Simon Eskildsen은 "모든 네임스페이스는 다른 키로 가능한 한 분리되어 물리적으로 휴지 상태에 있어야 했습니다."라고 말했습니다.

P99 대기 시간은 훨씬 더 상당한 이득을 보였으며, 이는 수많은 쿼리를 실행하는 에이전트 기반 워크플로우에 매우 중요합니다. 이러한 누적 대기 시간 감소는 복잡한 법률 AI 애플리케이션에서 반응성을 유지하는 데 필수적입니다.

Jacob Lauritzen은 "대기 시간이 기본적으로 한 자릿수 개선되었습니다. 그리고 이것들은 중앙값 대기 시간입니다. 따라서 P99는 훨씬 더 좋았습니다."라고 말했습니다.

법률 데이터는 도시, 카운티, 주 및 연방 법률과 같은 엄격한 계층 구조로 구성되어 있으며, 이 구조는 검색에서 유지되어야 합니다. 또한 시간적 유효성 및 규제 면제는 추가적인 검색 복잡성을 야기하며, 법률 내의 복잡한 그래프와 같은 관계로 인해 쿼리가 무거운 팬아웃을 포함해야 합니다.

Jacob Lauritzen은 "그것은 계층적입니다. 아시다시피, 도시와 카운티, 주, 그리고 연방 법률이 있으며, 전 세계가 마찬가지입니다."라고 설명했습니다.

Elasticsearch는 Legora의 대규모 법률 데이터 세트에 대해 비용이 많이 드는 것으로 판명되어 Turbopuffer로 전환하게 되었습니다. Turbopuffer의 아키텍처는 다른 관할권을 별도의 네임스페이스로 관리할 수 있도록 하여 계층화된 스토리지 전략을 가능하게 합니다. 이는 EU 법률과 같은 고트래픽 데이터를 빠른 액세스를 위해 "핫" 스토리지에 보관할 수 있고, 덴마크 법률과 같은 저트래픽 데이터는 "콜드" 스토리지에 보관할 수 있다는 것을 의미합니다. 이 디자인은 또한 콜드 블롭 스토리지에서 검색할 때 높은 대기 시간 허용 오차를 지원하여 전반적인 비용 효율성을 최적화합니다.

Jacob Lauritzen은 "Elasticsearch는 모든 것을 거기에 보관해야 했기 때문에 엄청나게 비싸졌지만, Turbopuffer를 사용하면 기본적으로 다른 관할권을 취하여 네임스페이스로 만들 수 있습니다."라고 언급했습니다.

'데이터를 부풀리는 것(puffing)'으로 비유되는 Turbopuffer의 설계는 효율적인 쿼리 실행을 위해 데이터가 특정 메모리 계층에 언제 상주해야 하는지를 숙달하는 데 중점을 둡니다. 이는 EU 법률과 같이 자주 쿼리되는 데이터가 NVMe 및 메모리 수준에 더 가깝게 전략적으로 배치된다는 것을 의미합니다. 데이터베이스 아키텍처는 계층 내 데이터 위치를 고려하여 왕복 및 데이터 액세스 패턴을 최적화하며, 궁극적인 목표는 가능한 한 많은 데이터를 최적의 스토리지 계층으로 푸시하는 것입니다.

Simon Eskildsen은 "Turbopuffer 이름의 또 다른 설명 중 하나는 데이터를 다른 메모리 계층으로 '부풀려' 특정 메모리 계층에 데이터가 언제 있어야 하는지를 정말로 숙달하는 것에 관한 것입니다."라고 자세히 설명했습니다.

Turbopuffer는 벡터를 클러스터로 조직하여 거대한 좌표계의 점으로 취급합니다. 이는 디스크 또는 객체 스토리지에서 노드를 탐색할 때 지연 시간 패널티를 겪는 전통적인 그래프 기반 접근 방식과 대조됩니다. 이 트리와 같은 클러스터 기반 조직은 벡터 검색 성능과 다양한 메모리 계층 간의 균형을 맞추도록 설계되었습니다. 디스크 기반 스토리지에 내재된 그래프 탐색 문제를 피함으로써 Turbopuffer는 다양한 메모리 계층에서 데이터 검색을 최적화합니다.

검색 대기 시간을 향상시키기 위해 Turbopuffer는 루트 센트로이드를 DRAM에 보관하여 트리 수준을 최적화합니다. 이 루트 센트로이드는 모든 검색 시 관련 클러스터를 식별하기 위해 액세스됩니다. 실제 데이터를 포함하는 리프 노드는 SSD에 상주합니다. 이 계층화된 접근 방식은 DRAM에 로드되는 데이터 양을 최소화하여 비용 효율적이며, 필요한 트리 상위 수준만 액세스하는 데 중점을 두어 웹 전체 인덱스와 같은 대규모 데이터 세트에 적합합니다.

Simon Eskildsen은 "이제 트리 상단의 루트 센트로이드는 검색할 때마다 항상 그 일부라고 상상할 수 있습니다. 우리는 항상 어떤 클러스터에 있는지 알아내려고 노력하고 항상 트리의 상위 수준을 보고 있습니다."라고 설명했습니다.

Turbopuffer의 전체 텍스트 검색은 기본적으로 해시맵처럼 작동합니다. 문서의 각 토큰은 문서 ID 세트에 매핑됩니다. 다중 용어 쿼리의 경우 시스템은 이러한 세트의 교차점을 수행하여 일치하는 문서를 찾습니다. 그런 다음 BM25 점수가 적용되어 단어 희귀도를 설명하고, 왕복 및 메모리 대역폭 요구 사항을 최소화하여 효율적이고 관련성 높은 검색 결과를 보장합니다.

Simon Eskildsen은 "텍스트 검색이 작동하는 방식은 기본적으로 해시맵이라고 생각할 수 있습니다. 큰 문서가 있고 모든 토큰을 가져와 해시맵의 키에 넣습니다."라고 설명했습니다.

그 성능은 효율적인 인덱스 압축과 대역폭 사용량 최소화에 크게 의존합니다. 이러한 복잡성은 방대하고 동적인 데이터 세트에서 높은 정밀도로 관련 텍스트 정보를 처리하고 검색해야 하는 필요성에서 비롯되며, 이는 상당한 엔지니어링 과제입니다.

Simon Eskildsen은 "대부분의 사람들에게 직관에 반하게도 웹 규모의 텍스트 검색은 벡터 검색보다 더 어렵고 계산 비용이 더 많이 듭니다."라고 관찰했습니다.

70개에서 200개 이상의 테넌트를 보유하고 있으므로 각 클라이언트별로 별도의 ElasticSearch 데이터베이스를 피하는 것이 확장성 및 비용 효율성에 매우 중요합니다. 이러한 전환을 통해 Legora는 복잡한 인프라 유지 관리에서 데이터 상주 요구 사항 및 전반적인 비용 최적화에 의해 주도되는 제품 개발 가속화로 초점을 변경할 수 있습니다.

Jacob Lauritzen은 "우리는 70개 이상의 테넌트, 100개, 200개의 테넌트를 가지고 있습니다. 아시다시피, 만약 우리가 각각의 테넌트를 위해 별도의 ElasticSearch 데이터베이스를 가지고 있어야 했다면, 그것은 지옥이었을 것입니다."라고 강조했습니다.