벡터 검색 (Vector search)은 질문과 의미론적으로 유사한 구절을 검색하는 효과적인 방법입니다. 하지만 이것이 모든 종류의 지식에 대한 보편적인 인터페이스는 아닙니다. 정확한 식별자 (Exact identifiers), 결정론적 계산 (Deterministic calculations), 그리고 여러 문서에 분산된 관계들은 서로 다른 검색 프리미티브 (Retrieval primitives)를 필요로 합니다.

실제 운영되는 지식 시스템 (Production knowledge system)은 현재 사용 가능한 데이터베이스가 아니라, 정보의 요구 사항 (Information need)에서부터 시작해야 합니다. 개방형 질문 (Open-ended questions)은 벡터 인덱스 (Vector index)에 속할 수 있습니다. 제품 코드는 정확한 일치 (Exact-match) 필드가 필요하며, 그 주변의 기술적 설명은 어휘 검색 (Lexical search)의 이점을 얻을 수도 있습니다. 정확한 합계는 구조화된 테이블 (Structured tables)에서 가져와야 합니다. 다중 홉 관계 (Multi-hop relationship) 질문은 그래프 탐색 (Graph traversals)으로 표현하는 것이 더 나을 수 있습니다.

따라서 검색 아키텍처 (Retrieval architecture)의 목적은 모든 질문을 하나의 검색 방법으로 강제하는 것이 아닙니다. 각 질문을 가장 신뢰성 있게 답변할 수 있는 표현 방식으로 라우팅 (Route)하고, 요청이 여러 형태의 지식에 걸쳐 있는 경우 방법들을 결합하는 것입니다.

의미론적 유사성 (Semantic Similarity)의 구조적 한계

조달 계약서, 제품 카탈로그, 송장이 포함된 문서 컬렉션을 가정해 봅시다.

한 계약서에는 A사가 공급업체 Beta로부터 산업용 센서를, 공급업체 Gamma로부터 제어 모듈을 구매한다는 내용이 명시되어 있습니다. 별도의 송장에는 Beta와 Gamma가 공급한 제품의 수량과 단가가 포함되어 있습니다. 사용자가 다음과 같이 질문합니다:

지난 분기 동안 A사가 승인된 공급업체로부터 구매한 모니터링 제품에 대한 총 지출액은 얼마입니까?

단일 구절이 반드시 이 질문과 유사할 필요는 없습니다. 답변을 위해서는 다음과 같은 여러 작업이 필요합니다:

1. A사의 승인된 공급업체를 식별합니다.
2. 어떤 제품이 모니터링 카테고리에 속하는지 식별합니다.
3. 해당 공급업체 및 제품을 요청된 기간과 연결하는 송장 품목 (Invoice line items)을 찾습니다.
4. 수량, 단가, 할인 및 세금 규칙을 바탕으로 총액을 계산합니다.

벡터 쿼리 (Vector query)는 Company A와 공급업체를 언급하고 있기 때문에 조달 계약 (procurement agreement)을 검색할 수도 있습니다. 또한 제품 모니터링에 관한 일반적인 구절을 검색할 수도 있습니다. 하지만 Company A에서 각 공급업체로 이어지는 관계를 추적하고, 해당 공급업체를 송장 행 (invoice rows)과 조인 (join)하며, 날짜 필터를 적용하고, 정확한 총액을 계산하도록 보장하는 메커니즘은 없습니다.

이는 더 큰 임베딩 모델 (embedding model)을 사용한다고 해서 항상 해결될 수 있는 약점이 아닙니다. 이 문제는 순수하게 의미론적 (semantic)이라기보다 관계적 (relational)이고 계산적 (computational)인 문제입니다.

검색 프리미티브 (Retrieval Primitives) 선택하기

실용적인 아키텍처는 하나의 정책 및 계획 레이어 (policy and planning layer) 뒤에 여러 가지 상호 보완적인 검색 방법을 노출할 수 있습니다.

소스 문서 및 운영 기록 (Source documents and operational records)
                  ↓
       버전 관리되는 인제스션 파이프라인 (Versioned ingestion pipeline)
...

의미를 위한 벡터 검색 (Vector Search for Meaning)

벡터 검색은 답변이 개념, 설명 또는 의역 (paraphrases)에 의존하는 질문에 적합합니다.

• 공급업체 계약에는 어떤 리스크가 설명되어 있습니까?
• 제품 문서에서는 교정 (calibration)을 어떻게 설명합니까?
• 파손된 상품에 대한 반품 조건을 요약하세요.
• 배송 일정이 왜 변경되었습니까?

이러한 질문들은 사용자의 표현 방식이 문서와 다를 수 있기 때문에 의미론적 매칭 (semantic matching)의 이점을 얻을 수 있습니다.

어휘적/밀집형 (lexical/dense) 분리는 검색 설계 공간의 전부가 아닙니다. SPLADE와 같은 학습된 희소 검색 (learned sparse retrieval)은 또 다른 검색 옵션으로 제시될 수 있습니다 [TODO-REF]. ColBERT와 같은 후기 상호작용 (late-interaction) 또는 다중 벡터 (multi-vector) 모델은 또 다른 비용과 품질 간의 트레이드오프 (trade-off)를 제공합니다 [TODO-REF]. 반정밀도 벡터 (half-precision vectors) 및 이진 양자화 (binary quantization)는 비용과 품질의 트레이드오프를 변화시키면서 인덱스 크기를 줄일 수 있습니다 [1]. 동일한 라우팅 및 퓨전 (fusion) 정책을 통해 이러한 방법들을 선택적 분기로 노출할 수 있으며, 선택은 보편적인 권장 사항으로 취급되는 대신 쿼리 클래스 (query class)에 의해 평가됩니다.

식별자를 위한 어휘적 및 완전 일치 검색 (Lexical and Exact-Match Retrieval for Identity)

정확한 식별자와 어휘적 관련성 (lexical relevance)은 서로 연관되어 있지만 서로 다른 검색 문제입니다. 제품 코드, 송장 번호, 계약 ID, 그리고 표준 공급업체 ID는 일반적으로 분석되지 않는 keyword 필드 또는 그에 상응하는 정확한 값 (exact-value) 컬럼에 저장되어야 합니다. 그러면 term 쿼리 또는 데이터베이스 등가 술어 (equality predicate)를 통해 부분적으로 매칭되는 토큰의 순위를 매기는 대신, 완전히 정규화된 식별자를 요구할 수 있습니다. 예를 들어, Elasticsearch는 정확한 키워드 검색과 분석된 전문 텍스트 (full-text) 쿼리를 구분하며, term 쿼리는 입력값을 분석하지 않는다는 점을 명시합니다 [2].

완전 일치 검색 (Exact-match retrieval)은 다음의 경우에 적합합니다:

• 제품 코드 PRD-482
• 송장 번호 INV-2026-0148
• 공급업체 참조 코드
• 계약 식별자

BM25는 전문 텍스트 어휘 분기 (full-text lexical branch)에 속합니다. BM25는 용어 통계 (term statistics)를 사용하여 분석된 텍스트의 순위를 매기며, 희귀 용어, 기술적 문구, 약어, 제품명, 그리고 문자 그대로의 표현이 중요한 구절에 특히 유용합니다. BM25는 전용 식별자 필드가 없는 경우에도 “differential pressure calibration”을 포함하는 조항을 검색할 수 있습니다. BM25는 어휘적 관련성을 위한 스코어링 모델 (scoring model)이지, 정확한 등가성 (exact equality)을 대체하는 것이 아닙니다 [3].

임베딩 공간 (Embedding spaces)은 의미적 유사성 (semantic similarity)을 나타냅니다. 불투명한 식별자 (opaque identifier)는 유용한 의미적 이웃 (semantic neighborhood)이 전혀 없을 수도 있습니다. 따라서 “PRD-482에 대한 교정 요구 사항을 설명해줘”와 같은 혼합된 요청은 제품 코드에 대해서는 정확한 필터 (exact filter)를, 문자 그대로의 기술 용어에 대해서는 BM25를, 설명 구절에 대해서는 벡터 검색 (vector retrieval)을 사용할 수 있습니다. 이러한 분기들을 별도로 유지하면 분석기 (analyzer)가 PRD-482를 오해의 소지가 있는 부분 일치 (partial matches)로 분할하는 것을 방지하고, BM25 점수 차이가 결정론적 조회 (deterministic lookup)를 변경하는 것을 방지할 수 있습니다.

결정론적 값 (Deterministic Values)을 위한 SQL

구조화된 데이터베이스 (Structured databases)는 정확한 필터, 집계 (aggregations), 그리고 계산 (calculations)이 필요한 질문에 답해야 합니다:

• 3월에 PRD-482의 단가는 얼마였습니까?
• Supplier Beta로부터 몇 개의 유닛이 구매되었습니까?
• 일련의 송장 (invoices) 전체의 총 세액은 얼마입니까?
• 총액이 임계값 (threshold)을 초과하는 송장은 무엇입니까?

이러한 답변은 관련 텍스트 청크 (text chunk)가 검색 결과 상위 5개에 포함되는지 여부에 의존해서는 안 됩니다. 수집 (ingestion) 과정에서 중요한 필드들이 추출되고 검증되면, SQL은 명시적인 필터, 반복 가능한 계산, 그리고 예측 가능한 타입 (types)을 제공합니다.

관계를 위한 지식 그래프 (Knowledge Graphs)

지식 그래프 (knowledge graph)는 사실을 엔티티 (entities) 간의 관계로 나타냅니다. 텍스트 구절만을 저장하는 대신, 다음과 같은 트리플 (triples)을 저장할 수 있습니다:

(Company A) -[APPROVED_VENDOR]-> (Supplier Beta)
(Supplier Beta) -[SUPPLIES]-> (PRD-482)
(PRD-482) -[BELONGS_TO]-> (Monitoring Products)

그래프는 질문이 경로 (paths)를 포함할 때 유용합니다: 특정 회사의 공급업체, 해당 공급업체가 공급하는 제품, 관련 계약, 또는 여러 엔티티에 걸친 의존성 (dependencies) 등이 이에 해당합니다. 그래프는 원본 문서를 대체하지 않습니다. 모든 관계는 그것이 추출된 청크 (chunk) 또는 구조화된 레코드 (structured record)에 대한 링크를 유지해야 합니다.

지식 그래프를 도입할 가치가 있는 경우

모든 검색 시스템(retrieval system)에 지식 그래프(knowledge graph)가 필수적인 것은 아닙니다. 관계가 단순하고 안정적이며 이미 외래 키(foreign keys)로 표현되어 있다면, 인덱싱된 SQL 조인(join)이 운영하기 더 쉬운 경우가 많으며 더 적은 동기화 복사본으로도 질문에 답할 수 있습니다. 기업-공급업체 관계와 공급업체-제품 테이블이 있다고 해서 자동으로 그래프 데이터베이스(graph database)를 정당화할 수 있는 것은 아닙니다.

다중 홉 탐색(multi-hop traversal)이 빈번하고, 동일한 관계가 많은 쿼리 유형을 지원하며, 경로 구조(path structure)가 답변의 일부가 되고, 엔티티 해상도(entity resolution)가 중복되거나 잘못 병합된 노드를 방지할 수 있을 만큼 신뢰할 수 있을 때 그래프는 더욱 강력한 설득력을 갖습니다. 또한 도메인에서 이기종 소스(heterogeneous sources)에 걸쳐 재사용 가능한 관계 출처(relationship provenance)나 시간적 엣지(temporal edges)가 필요한 경우에도 유용합니다.

트레이드오프(trade-off)는 운영 측면에서 발생합니다. 그래프는 또 다른 스키마(schema), 쿼리 언어(query language), 스토리지 엔진(storage engine), 권한 부여 영역(authorization surface), 배포, 백업 경로 및 동기화 프로세스를 도입합니다. 엣지 추출(edge extraction)과 엔티티 해상도(entity resolution)를 모니터링해야 하며, 업데이트와 삭제가 전파되어야 하고, 그래프 결과는 SQL 및 문서 인덱스(document indexes)와 일관성을 유지해야 합니다. 이러한 비용이 관계형 조인(relational joins)을 통해 얻는 측정된 이익을 초과한다면, SQL을 관계 저장소로 유지해야 합니다.

수집(Ingestion) 단계에서의 다중 표현 구축

하이브리드 검색(Hybrid retrieval)은 수집(ingestion) 단계부터 시작됩니다. 동일한 소스 문서에서 여러 개의 동기화된 표현(representations)을 생성할 수 있습니다:

• 감사 및 표시를 위한 원본 문서
• 의미론적(semantic) 및 BM25 어휘 검색(lexical search)을 위한 파싱된 청크(parsed chunks)
• 정확한 일치 검색(exact-match retrieval)을 위한 정규화된 식별자 필드(normalized identifier fields)
• 벡터 인덱스(vector index)를 위한 임베딩(embeddings)
• 관계형 테이블을 위한 검증된 필드(validated fields)
• 그래프를 위한 정규화된 엔티티(entities) 및 관계(relationships)

이러한 표현들은 안정적인 식별자(identifiers)를 공유해야 합니다. 조달 계약서에서 추출된 관계에는 소스 문서 ID, 페이지 번호, 청크 ID, 추출 버전 및 타임스탬프(timestamp)가 포함되어야 합니다. 구조화된 인보이스(invoice) 행 또한 동일한 출처(provenance)를 보존해야 합니다.

예를 들어:

{
  "source_entity": "Company A",
  "relationship": "APPROVED_VENDOR",
...

출처(Provenance)는 두 가지 목적을 수행합니다. 생성된 답변이 증거를 인용할 수 있게 해주며, 잘못된 그래프 엣지(edge)가 이를 생성한 추출(extraction) 단계로 추적될 수 있게 합니다.

청크 경계 (Chunk Boundaries)

청크 경계는 레이아웃 구조를 따르거나 고정 크기 규칙을 따를 수 있습니다. 레이아웃 인식 분할(Layout-aware splitting)은 헤딩(heading), 절(clause), 리스트(list), 페이지 영역을 보존할 수 있는 반면, 고정 크기 분할(fixed-size splitting)은 예측 가능한 단위를 제공하지만 구조를 가로질러 끊길 수 있습니다. 표(table)와 식별자 블록(identifier blocks)은 레코드 중간에서 분할되어서는 안 됩니다. 결과물인 청크가 헤더(header), 단위(unit), 또는 정확한 식별자(identifier)를 잃어버릴 수 있기 때문입니다.

중첩(Overlap)은 경계 근처의 문맥을 보존할 수 있지만, ## 하이브리드 검색 결과 결합 (Combining Hybrid Retrieval Results) 단계의 중복 제거(deduplication) 과정에서 처리해야 하는 중복 증거 비용을 발생시킵니다. 업데이트 전파(update propagation)와 부모 문서 집계(parent-document aggregation)를 위해서는 안정적인 청크 ID(chunk ID)와 자식-부모 매핑(child-to-parent mappings)이 필요합니다. 경계 정책(Boundary policy)은 상수가 아니라 평가되는 파라미터(parameter)입니다. [저자: 이 코퍼스에 대한 측정된 청크 크기/중첩 결과 삽입]

그래프에서의 스키마 규율 (Schema Discipline in the Graph)

그래프 추출(Graph extraction)은 제약이 없는 언어 모델(language-model) 작업이 되어서는 안 됩니다. 만약 동일한 관계가 SUPPLIER, SUPPLIES_TO, VENDOR_OF, PROVIDES_FOR와 같이 각각 저장된다면, 그래프 쿼리(graph queries)는 일관성을 잃게 됩니다.

제어된 스키마(controlled schema)는 다음을 정의해야 합니다:

• 지원되는 엔티티 유형 (Supported entity types)
• 표준 관계 이름 (Canonical relationship names)
• 필수 속성 (Required properties)
• 각 관계의 방향 (Direction of each relationship)
• 유효한 소스(source) 및 타겟(target) 유형
• 시간적 속성 (Temporal properties)
• 엔티티 이름에 대한 정규화 규칙 (Normalization rules for entity names)

추출 모델은 이 스키마를 준수하는 구조화된 출력(structured output)을 반환해야 합니다. 유효하지 않은 관계 유형은 거부되거나 검토(review) 단계로 라우팅(routed)되어야 합니다. 엔티티 해상도(Entity resolution)는 중복 노드를 생성하는 대신 철자 변형과 별칭(alias)을 안정적인 ID로 매핑해야 합니다.

시간 정보(Temporal information) 또한 중요합니다. 공급업체 관계는 계약 기간 동안에만 유효할 수 있습니다. 제품 카테고리는 변경될 수 있습니다. 따라서 도메인에서 이력 기반의 답변(historical answers)이 필요한 경우, 그래프 에지(Graph edges)는 유효 날짜(effective dates) 또는 문서 버전 참조(document-version references)를 지원해야 합니다.

인제스션 라이프사이클 및 스토어 간 일관성 (Ingestion Lifecycle and Cross-Store Consistency)

하나의 소스로부터 여러 개의 표현(representations)을 생성하는 것은 일관성 문제를 야기합니다. 따라서 프로덕션 인제스션(Production ingestion)은 멱등성(idempotent)을 가져야 합니다. 즉, 동일한 추출 설정(extraction configuration)으로 동일한 문서 버전(document version)을 다시 재생(replaying)하더라도 중복된 청크(chunks), 송장 행(invoice rows), 엔티티(entities) 또는 에지(edges)가 생성되어서는 안 됩니다. 콘텐츠 해시(Content hash), 안정적인 소스 ID(stable source ID), 문서 버전(document version), 그리고 결정론적 자식 ID(deterministic child IDs)를 사용하면 파이프라인이 반복된 작업을 인식하고 업서트(upserts)를 안전하게 수행할 수 있습니다.