Parallax의 문헌 검색: 집합 대수, 전체 코퍼스 재현율, Jev 스크리닝

동기

AI 논문은 그 어느 때보다 빠르게 출판되고 있고, 문헌 검색은 이제 진짜 어려운 문제가 되었습니다. 범용 에이전트나 코딩 에이전트로 문헌 검색(관련 연구 찾기, 또는 한 분야의 지형 파악하기)을 해 보면서 계속해서 두 가지 한계에 부딪혔습니다:

1. 범용 에이전트는 블랙박스 검색 API를 통해 오픈 웹을 검색합니다. 보통 상위 k개 결과만 받기 때문에 전체를 빠짐없이 훑을 수 없고, "이 분야에 논문이 몇 편이나 있나?" 같은 질문에는 답할 수 없습니다.
2. 검색 API의 결과는 노이즈가 많습니다. 인터넷 전체를 대상으로 하기 때문에 데이터를 정리하고 구조화하는 데 추가 노력이 들어갑니다.

이 때문에 에이전트는 논문을 검색할 때 일찍 멈추는 경향이 있고, 아니면 느리고 비싸지고 맙니다. 올해 초에 저는 개인용 파이프라인을 바이브코딩으로 만들었습니다: arXiv 메타데이터 크롤링 -> 임베딩 -> 키워드 또는 시맨틱 리콜 -> LLM 스크리닝. 여전히 꽤 비쌌고 스크리닝도 느려서 쓰기 좋다는 느낌이 들지 않았습니다.

9월 중순에 Jev가 나왔고, 리콜 이후의 논문 스크리닝과 분류에 아주 잘 맞는다는 걸 깨달았습니다. 그래서 Jev 위에서 제 문헌 인프라를 다시 짓기 시작했습니다. 이 GIF가 스크리닝이 얼마나 빠른지 보여줍니다:

이 글의 나머지에서는 검색 시스템이 어떻게 설계되었는지, 그리고 프로덕션에서 돌리기 위해 필요했던 몇 가지 최적화를 다룹니다.

검색 구조

저는 한동안 추천 시스템을 했지만 에이전틱 검색은 많이 해 보지 않았고, 그때의 습관을 몇 가지 그대로 가져왔습니다. 처음 떠올린 아이디어는 퍼널이었습니다: 리콜, 거친 랭킹, 정밀 스크리닝. 논문 검색은 피드 추천과 꽤 다르다는 게 드러났습니다:

• 확장이 필요합니다: 논문은 서로를 인용하고, 초기 논문의 인용을 따라가는 것은 더 많은 연구를 찾는 아주 흔한 방법입니다.
• 보완이 필요합니다: 사람이 검색하든 에이전트가 검색하든 빠지는 것이 생깁니다. 첫 패스 이후에는 부적합한 것이 들어오지 않았는지, 또는 앞서 눈에 띈 것이 빠지지 않았는지 확인하는 검토 단계가 필요합니다.

퍼널만으로는 이것에 분명히 부족합니다. 여러 리콜 채널을 병합하고 중복 제거해야 하는 필요, 그리고 오탐을 대량으로 제거해야 하는 필요까지 더하면, 집합이 이 문제에 좋은 자료구조라는 결론에 이릅니다. 그래서 검색 레이어 전체를 집합 대수 인터페이스 중심으로 다시 작성했습니다.

에이전트가 다루는 기본 단위는 논문 집합입니다(일반적인 성질을 가집니다: 잘 정의되고, 원소가 서로 다르고, 순서가 없음). 합집합, 교집합, 차집합을 지원하고, 몇 가지 실용적인 객체와 연산자도 있습니다:

• 가상 루트: 전체 코퍼스나 특정 날짜의 arXiv 공지에 실린 논문 등 시작점을 나타내는 가상 객체입니다. 가상 루트는 방대한 수의 멤버를 영속화해 저장 공간을 과도하게 차지하는 일을 피합니다.
• 규칙 필터: arXiv 카테고리, 시간 범위, 리소스 유형, 임베딩 유사도, 키워드 매칭 등으로 논문을 필터링합니다.
• AI 스크리닝: Jev를 사용해, 에이전트가 사용자 의도에 기반해 작성한 기준에 비추어 각 논문을 판정합니다.
• AI 분류: Jev의 다중 레이블 확률 인터페이스를 사용해 논문을 분류합니다. 논문은 둘 이상의 카테고리에 속할 수 있으므로 카테고리는 상호 배타적이지 않습니다.

검색 시스템 전체는 노드 그래프로 시각화되며, 프론트엔드에서 ReactFlow로 구축했습니다. 노드 그래프는 온갖 실제 요구를 처리하기에 충분히 유연합니다.

일반적인 워크플로는 위에 표시된 것과 같습니다. 여러 키워드 및 시맨틱 리콜 채널, 이들을 병합하고 중복을 제거하여 대규모 후보 집합으로 만드는 합집합 노드, Jev를 호출하는 AI 스크리닝 노드, 그리고 주제별로 논문을 분류하는 AI 분류 노드가 있습니다.

대부분의 경우 에이전트는 이 일반적인 워크플로를 따릅니다. 그러나 더 크고 복잡한 요청의 경우 검토 중에 누락된 부분을 발견하고, 이를 채우기 위한 새로운 집합을 구축하며, 분류로 넘어가기 전에 "최종" 집합에 도달할 때까지 반복할 수 있습니다. 그 결과 만들어지는 워크플로는 회로도만큼 복잡해질 수 있습니다.

일반 에이전트와 코딩 에이전트는 보통 결과를 텍스트 파일에, 또는 스크립트로 처리되는 XML/JSON에 기록합니다. 집합을 인덱스가 있는 데이터베이스에 보관하는 방식은 훨씬 더 크게 확장할 수 있고 훨씬 더 효율적입니다. 이런 종류의 대규모 처리를 결정론적 코드에 맡기는 것은 모델 환각을 방지하고 컨텍스트가 압축될 때 세부 사항이 유실되는 것도 방지합니다. 에이전트는 집합에 대한 핸들만 보유하며, 모든 멤버 수준 작업은 데이터베이스 내부에서 이루어집니다.

또 다른 실질적인 문제는 리콜 깊이입니다. 키워드 매칭은 적중이거나 아니거나 둘 중 하나이지만, 시맨틱 리콜은 순위 매김입니다. 순위 300은 여전히 관련이 있을 수 있지만 순위 3000은 이미 주제에서 벗어났을 수 있으며, K를 미리 고르기는 어렵습니다. 그래서 집합을 만들기 전에 에이전트는 먼저 총 개수, 몇 개의 샘플, 분포만 반환하는 저비용 프로브를 실행합니다. 시맨틱 리콜의 경우 프로브에는 순위 대 유사도 곡선도 포함되며, 에이전트는 그 곡선의 엘보를 기준으로 어디에서 자를지 결정할 수 있습니다.

초기 버전에서는 프로브와 집합 생성이 두 개의 별도 계산이었습니다. 동일한 top-10000 시맨틱 쿼리에 대해 프로브는 2분이 걸렸고, 집합 생성은 모든 것을 다시 계산하느라 37분이 더 걸렸습니다. 이제는 프로브의 전체 순위가 저장되며, 집합 생성은 그로부터 상위 N개를 가져오기만 하면 되고 재계산은 없습니다.

리콜 성능

위의 아이디어는 상당히 자연스럽습니다. ComfyUI 같은 로우코드 노드 그래프 도구는 이미 널리 알려져 있으며, 많은 사람들이 문헌 검색을 위해 비슷한 것을 생각해 봤을 것입니다. 이런 시스템을 프로덕션에 도입할 때 어려운 부분은 데이터 추상화가 아닙니다. 규모에서의 성능, 그리고 속도, 비용, 품질의 균형입니다.

Parallax는 현재 OAI 인터페이스를 통해 2020년 이후 arXiv cs.* 카테고리의 메타데이터 업데이트를 수집하며, 약 820,000편의 논문입니다. 메타데이터와 그 인덱스는 약 7.8 GB를 차지합니다. 시맨틱 리콜에는 Perplexity의 pplx-embed-v1-0.6b를 사용하여 각 초록을 1024차원 벡터로 임베딩합니다. float32에서는 벡터당 4 KB로, 820,000편에 대해 이론상 약 3.3 GB입니다. halfvec(반정밀도)으로는 각각 2 KB로 총 약 1.65 GB입니다. 그러나 이것은 원시 데이터에 불과합니다. PostgreSQL + pgvector에서는 정확성과 속도를 모두 확보하기 위해 벡터를 한 가지 이상의 형태로 저장하며, 인덱스를 포함하면 총 약 17 GB가 됩니다.

키워드 리콜

PostgreSQL에서 퍼지 매칭을 하는 일반적인 방법은 트라이그램 인덱스입니다. 텍스트를 세 글자 조각으로 나누고, 역색인을 구축하고, 그 조각들로 후보를 찾은 다음, 원본 텍스트를 확인하기 위해 테이블로 돌아갑니다. 그러나 일반적인 구문에서는 성능이 나쁩니다. 약 690,000편의 논문 코퍼스에서 초록에서 motion generation를 검색하면 트라이그램 인덱스를 사용하기는 했지만 34초가 걸렸고, 그중 32초는 IO 대기에 소요되었습니다. mot, ion, gen 같은 조각들은 너무 흔합니다. 인덱스가 25,000개의 후보를 생성했지만 실제로 일치한 것은 776개뿐이었고, 수만 건의 테이블 조회가 낭비되었습니다.

우리의 수정 방안은 인접 단어 조각 인덱스를 추가하는 것이었습니다. 제목이나 초록에 있는 인접한 두 단어마다 첫 번째 단어의 마지막 3개 문자와 두 번째 단어의 처음 3개 문자(그리고 5개 문자 버전)를 취해 하나의 조각으로 결합합니다. 예를 들어 motion generation는 ion:gen과 otion:gener을 생성합니다. 이것들은 GIN 배열 인덱스에 들어갑니다. 두 개의 특정 단어가 서로 옆에 나타나는 것은 단일 3개 문자 조각보다 훨씬 드물기 때문에 후보 집합이 크게 줄어듭니다. 단어가 충분히 길 때는 5개 문자 버전을 선호하는데, ion:gen 같은 조합이 여전히 상당히 흔하기 때문입니다.

조각은 필요한 조건으로만 사용됩니다. 최종 확인은 여전히 원본 텍스트에 대한 기존의 필드별 ILIKE이므로 결과 집합은 이전 구현과 동일하고 반환되는 개수도 정확합니다. 변경 후 동일한 단일 구문 쿼리는 약 30ms가 걸리며, agent가 흔히 실행하는 일곱 구문 쿼리는 23초에서 0.09초로 줄었고, 동일한 스냅샷에서 이전 버전과 새 버전의 논문 ID가 하나씩 일치했습니다.

시맨틱 리콜

벡터 검색은 항상 속도와 정확성 사이의 트레이드오프를 수반합니다. 정확 검색은 모든 후보 벡터를 스캔합니다. HNSW 같은 근사 최근접 이웃(ANN) 인덱스는 훨씬 빠르지만 결과를 놓치며, K가 커질수록 더 많이 놓칩니다. 우리는 결국 두 경로를 유지하고 그 사이를 자동으로 선택하기로 했습니다.

근사 경로는 파티셔닝 + 반정밀도 + 재랭킹을 사용합니다:

• 1024차원 float32 HNSW 인덱스는 4.4 GB입니다. 캐시되지 않았을 때 한 번의 쿼리가 수백 MB의 인덱스 페이지를 읽고 인덱스가 있어도 20초 이상 걸립니다. 그래서 인덱스는 크기를 절반으로 줄이는 halfvec을 사용하며, 후보를 찾는 데에만 사용됩니다.
• 필요한 것보다 몇 배 더 많은 후보를 가져온 다음, 반정밀도로 인한 오차를 보정하기 위해 원본 float32 벡터로 다시 점수를 매기고 정렬합니다.
• 벡터는 연도별로 파티셔닝되며, 각 파티션은 자체 HNSW 그래프를 가집니다. 사용자가 시간 범위를 지정하면 관련 없는 연도는 건너뜁니다.

핵심 ANN 파라미터는 탐색 폭 ef_search와 후보 풀 배수입니다. 정확한 top-K를 기준 진값으로 삼아, 프로덕션의 실제 시맨틱 쿼리 32개에서 설정을 비교했습니다:

놓친 논문은 거의 모두 K 순위 바로 근처에 있으며, 유사도가 K번째 결과보다 수천분의 몇 수준만 낮으므로 실제 결과에 미치는 영향은 리콜 수치가 시사하는 것보다 작습니다.

넓은 시간 범위, 큰 K, 또는 ANN 타임아웃의 경우 정확 경로로 전환합니다. 전체 코퍼스에 대해 단일 정확 리콜 SQL을 실행하면 런타임이 예측 불가능하고, 중단되면 체크포인트가 없어 처음부터 다시 시작해야 합니다. 대신 후보를 배치로 나누어 각 배치의 top-K를 계산한 다음 병합하여 전체 top-K를 취합니다.

정밀도 손실은 없습니다. 어떤 논문이 전체 상위 K개 안에 있다면, 전체 코퍼스에서 그보다 높은 점수를 받은 논문은 K개 미만이므로, 해당 논문이 속한 배치에서도 그보다 높은 점수를 받은 논문은 K개 미만입니다. 따라서 반드시 해당 배치의 상위 K개 안에 들어야 하며 병합 과정에서 탈락할 수 없습니다. 모든 배치가 동일한 점수 산정 방식과 동일한 정렬 순서(동점은 논문 ID로 처리)를 사용하는 한, 배치 처리 결과는 전체를 한 번에 정렬한 결과와 정확히 같습니다.

배치 처리에는 약간의 시간 오버헤드가 추가되지만 안정성과 리소스 제어는 모두 개선됩니다. 각 배치는 완료되는 즉시 저장되므로 재시작된 프로세스는 중단된 지점부터 계속합니다. 시간 초과된 배치는 두 개의 더 작은 배치로 분할됩니다. 대규모 작업은 배치 사이에 리소스를 양보하므로 다른 사용자의 소규모 쿼리를 막지 않습니다. 프로덕션 데이터베이스에서 인수 테스트를 실행했습니다. 전체 코퍼스에서 810,000개의 후보, K=5000, 407개 배치로 약 5분 만에 완료되었습니다. 동일한 스냅샷에서 한 번에 실행한 float32 정확 쿼리와 비교했을 때, 5000개 결과 모두 ID, 순서, 점수가 일치했습니다.

스크리닝과 분류

처음 시작한 DeepSeek-Flash 스크리닝과 비교하면, 9월 말 Jev로 전환한 후 새 파이프라인은 프로덕션 서버에서 36,564편의 논문을 약 5분 만에 스크리닝했습니다. 이는 LLM 버전보다 10배 이상 빠르며 비용은 5분의 1 미만입니다.

LLM이 왜 더 비싸고 느린가요? 우리 파이프라인이 각 결정에 대한 감사 정보(확률 또는 이유)를 수집하기 때문입니다. LLM은 true 또는 false만 출력하지 않고 결정과 이유를 담은 JSON을 출력합니다. CoT 추론을 켜면 추론 길이를 예측할 수 없어 지연 시간도 예측할 수 없습니다. CoT를 끄면 배치 처리가 잘못된 JSON을 생성하는 경우가 많아, 배치 전체를 버리고 재시도하거나 실패한 항목을 모아 새 배치로 만들어야 합니다.

반면 Jev의 인터페이스는 컨텍스트(상태)와 질문 집합을 받아 보정된 확률을 직접 반환합니다. 스크리닝과 분류 모두 Jev의 Noul 원시 연산을 기반으로 합니다. 스크리닝의 경우 논문 한 편과 에이전트가 작성한 포함/제외 기준을 입력으로 하며, 확률이 0.5 이상이면 논문이 포함됩니다. 분류의 경우 각 카테고리에 자체 Noul이 있고 독립적으로 판정합니다. 0.8 이상은 적중으로 간주하고, 0.2에서 0.8은 불확실로 표시하여 사용자와 에이전트가 검토합니다. 출력은 설계상 구조화되어 있어 잘못된 출력 문제가 없으며, 모든 논문의 모든 기준에 대한 확률이 데이터베이스에 저장됩니다.

다중 레이블 분류의 입력 형식

다중 레이블 분류에서는 각 논문이 십여 개의 카테고리 질문에 답해야 합니다. 원래 형식은 모든 질문에서 논문의 제목과 초록을 반복하여 많은 토큰을 낭비했습니다. 개선 방법은 논문을 공유 상태에 넣고 모든 카테고리 질문이 이를 참조하도록 하는 것이었습니다. 한 걸음 더 나아가: 상태에 논문 다섯 편을 넣고 한 번의 요청으로 다섯 편 모두의 모든 카테고리를 질문할 수 있을까요? 120편의 실제 논문과 열두 개 카테고리로 이 옵션들을 비교했습니다:

속도와 비용만 놓고 보면 요청당 논문 다섯 편이 이긴다. 그러나 같은 그룹화를 두 번 실행했을 때 결과가 달라진 논문은 1편뿐이었던 반면, 120편의 논문을 섞어 새 그룹으로 나누자 약 20편의 레이블이 바뀌었다. 예를 들어 초록에 그래프 신경망을 명시적으로 언급한 한 논문은 단독으로 판정했을 때 "graph learning" 범주에서 0.95를 받았지만, 다른 네 편과 함께 그룹으로 묶였을 때는 0.78로 떨어져 적중 임계값 아래로 내려갔다.

다시 말해, 그룹 내 다른 논문이 모델이 이 논문을 판정하는 방식에 영향을 준다는 것이며, 이는 분류에 있어 받아들일 수 없다. 따라서 기본적으로 각 요청에는 논문 한 편만 포함되고, 그 요청에서 열두 개 범주를 모두 판정한다. 이는 논문 간 간섭 없이 원래 형식보다 입력 토큰을 약 66% 덜 사용한다.

배치 처리와 동시성

Jev 요청 하나는 수백 밀리초밖에 걸리지 않지만, 수만 편의 논문을 안정적으로 처리하려면 모델 외부에서 많은 작업이 필요하다:

• 적응형 패킹: 스크리닝의 배치 크기는 고정되어 있지 않다. Jev의 컨텍스트 윈도우와 현재 배치에 있는 메타데이터의 토큰 길이로부터 계산된다. 첫 구현은 논문을 하나씩 시도하고 매번 전체 배치의 토큰을 다시 추정했기 때문에 배치가 커질수록 느려졌다. 들어갈 수 있는 가장 큰 접두사를 이진 탐색으로 찾는 방식으로 바꾸자 패킹 오버헤드가 크게 줄었고, 전송되는 요청은 완전히 동일하게 유지되었다.
• 속도 제한: 계정에는 초당 요청 수와 초당 토큰 수에 대한 할당량이 있다. 우리는 GCRA 알고리즘으로 이론적 전송 시각을 기준으로 진행하므로, 락 대기와 스레드 스케줄링이 더 이상 할당량을 잡아먹지 않는다. 속도 제한이 병목일 때 실제 처리량은 할당량의 73%에서 98%로 올라갔다.
• 공정성: 모든 작업이 하나의 계정 할당량을 공유하며, 대기할 때 진행 중인 요청이 적은 사용자가 먼저 처리되므로 작은 작업이 큰 작업에 굶주리지 않는다.

프로파일링 결과 한동안 처리량은 네트워크도 모델도 아닌, 우리 워커 프로세스가 CPU를 한계까지 사용하는 데서 제한되고 있었다. 각 HTTP 요청에는 비용 예약, 전송 전 검사, 정산, 결과 영속화를 아우르는 약 120개의 SQL 문이 관여했으며, 이는 모든 호출을 복구 가능하게 하고, 절대 이중 청구되지 않게 하며, 문제가 생겼을 때 추적 가능하게 하기 위한 것이었다. 처리량이 더 올라가기 전에, 우리는 요청당 할당량 관련 SQL을 약 36개에서 약 15개로 줄이고, 거의 동시에 완료되는 결과들을 단일 커밋으로 묶었다.

입력 토큰 기준으로 논문 한 편을 스크리닝하는 데 300여 개의 토큰이 조금 넘게 들므로, 논문 만 편을 스크리닝하는 비용은 대략 1위안(약 15센트)이다. 스크리닝이 이렇게 저렴해지자 에이전트의 행동도 달라졌다. 예전에는 스크리닝 전에 후보 집합을 최대한 줄였지만, 이제는 넓게 회수하여 관련 있을 수 있는 모든 것을 끌어오고 Jev가 각 논문을 판정하게 할 수 있다.

결과

"LLM 에이전트를 위한 메모리 메커니즘" 검색에서, 에이전트는 먼저 사용자의 힌트를 바탕으로 코퍼스에 저비용 프로브를 실행해 논문의 대략적인 분포를 파악했다. 그런 다음 6개의 키워드 회수 채널과 5개의 의미 회수 채널을 만들었고, 이들은 삼만 개가 넘는 후보로 병합되었다. 에이전트는 Jev를 위한 기준, 즉 어떤 종류의 논문을 포함하고 무엇을 제외할지를 작성하여 백그라운드에서 동시 배치 판정에 제출했다.

다른 작업인 "8월 멀티모달 이해 및 통합 멀티모달 모델 연구 리뷰"에서 에이전트는 세 개의 키워드 및 의미 기반 리콜 채널에서 466개의 후보를 얻었고, 스크리닝을 통해 주제에 부합하는 428편의 논문을 유지했습니다. 그런 다음 에이전트는 해당 집합의 제목을 읽고 카테고리 목록 초안을 작성한 뒤 Jev 분류 노드를 호출했습니다. 그 결과 벤치마크 및 데이터셋, 임베디드 AI, 안전 및 프라이버시, 통합 이해 및 생성을 포함한 10개의 카테고리가 나왔습니다.

사용자는 벤치마크 카테고리에 여전히 100편이 넘는 논문이 있어 추가로 분할할 수 있다고 지적했고, 이에 에이전트는 해당 항목들을 살펴보고 벤치마크 하위 집합을 11개의 하위 카테고리로 나누었습니다.

분류 과정에서 Jev는 각 논문에 대해 각 카테고리 기준에 대한 포함 확률을 부여합니다. 이 확률은 모두 데이터베이스에 저장되어 사용자와 에이전트가 검토할 수 있습니다.

왜 Parallax인가?

왜 Parallax를 만드는가? 재귀적 자기 개선이 정말로 도래하여 AI 논문이 완전히 가치를 잃기 전까지, arXiv 논문은 최전선 연구소 밖의 연구자, 학생, 개발자에게 해당 분야에 관한 일차 정보원으로 남아 있습니다. 그러나 점점 더 많은 논문이 출판되고 그 논문들이 collectively 점점 더 많은 통찰을 담게 되면서, 사람들이 논문의 증가 속도에 맞는 속도로 분야를 이해하기는 점점 더 어려워지고 있습니다.

나는 모든 관련 논문을 찾아내고, 전체 분야 또는 내가 관심 있는 틈새 분야에서 공간과 시간에 걸쳐 무슨 일이 일어났는지 보고 싶습니다. 그렇게 할 수 있는 유일한 방법은 전체 코퍼스에 대한 빠른 리콜 스캔이며, Google Search나 arXiv Search의 top-K 결과로는 거기에 도달할 수 없습니다. "모든 것을 찾기"에 대한 수요는 GitHub의 수많은 awesome paper 목록에서 분명히 드러납니다.

1년 반 전, 내가 아직 게임 업계에서 일할 때, 우리 사용자 리서치 팀이 새로운 장르가 형성되는 것을 어떻게 지켜보는지에 관한 발표를 들었습니다. Steam 태그는 플레이어가 만들며, 리뷰와 태그를 지속적으로 추적하면 어떤 표현이 산발적인 언급에서 대부분의 플레이어가 사용하는 것으로 변해 새로운 "장르"가 되는 과정을 볼 수 있습니다. "Soulslike"와 "Metroidvania"도 그렇게 시작했습니다. 원래 플레이어들은 단지 "이 게임은 Dark Souls만큼 어렵고 이야기를 전하는 방식도 같다"거나 "이건 Metroid와 Castlevania처럼 플레이된다"는 뜻이었습니다.

arXiv 논문의 폭발은 AI 연구를 고빈도, 빠르게 움직이는 시기로 몰아넣었고, Jev는 나에게 분야가 어떻게 변화하는지 지켜볼 훨씬 저렴하고 유연한 방법을 보여주었습니다.

Parallax는 라이브 상태입니다. https://parallax.ink 에서 가입하여 사용해 보시기 바랍니다.