Oracle에서의 벡터 네이티브 RAG: 임베딩(embeddings), HNSW/IVF 및 데이터베이스 거버넌스 하의 하이브리드 검색

핵심 요약 (Key Takeaways)

콘텐츠, 메타데이터 및 출처(provenance)와 함께 Oracle VECTOR 컬럼에 벡터를 저장한다는 것은 검색이 데이터베이스 내부에서 수행됨을 의미합니다. 기존의 거버넌스 — 행 수준 보안(row-level security), 감사(auditing), 데이터 마스킹(data masking) — 가 다른 모든 쿼리와 동일하게 벡터 쿼리에도 적용됩니다.
하이브리드 검색(Hybrid retrieval)은 일반적인 SQL입니다: VECTOR_DISTANCE는 의미론적 유사성(semantic similarity)을 처리하고, WHERE 절은 동일한 문장에서 비즈니스 서술어(business predicates)를 처리합니다. 쿼리를 읽을 수 있는 검토자라면 어떤 행이 왜 자격을 갖추었는지 이해할 수 있습니다.
HNSW와 IVF는 재현율(recall), 메모리 사용량(memory footprint), 쿼리 지연 시간(query latency) 측면에서 실제적인 트레이드오프(trade-offs)가 있는 인덱스 전략입니다. 이들 사이의 선택은 자체 코퍼스(corpus)에서 두 가지를 모두 측정해야 하며, 서로 교체 가능한 기본값(defaults)이 아닙니다.
답변 단계 또한 검사 가능한 상태로 유지될 수 있습니다. 검색을 SHOWSQL이 포함된 Select AI 프로필에 연결하면, 검색 단계뿐만 아니라 SQL 생성 단계도 검토할 수 있습니다.

검색 증강 생성(Retrieval-augmented generation, RAG)은 적절한 컨텍스트를 빠르게 가져오고, 왜 해당 행들이 자격을 갖추었는지 일반 SQL로 설명할 수 있을 때 효과적으로 작동합니다. 독립형 벡터 스토어(stand-alone vector store)와 기록용 데이터베이스(database of record) 사이에 저장소를 분리하면 초기 프로토타입 제작 속도는 빨라지지만 거버넌스가 취약해집니다. 메타데이터가 중복되고, 필터가 재구현되며, 감사 추적(audit trails)이 종종 제어할 수 없는 게이트웨이에서 끊기기 때문입니다. Oracle의 벡터 네이티브(vector-native) 접근 방식은 전체 RAG 경로를 데이터베이스 내부에 유지합니다. 임베딩(Embeddings)은 이미 추적 중인 텍스트, JSON 및 출처와 함께 VECTOR 컬럼에 상주합니다. CREATE VECTOR INDEX를 사용하여 HNSW 또는 IVF로 인덱싱할 수 있으며, 의미론적 유사성과 비즈니스 서술어를 결합한 SQL로 검색할 수 있습니다. 검색이 데이터베이스 객체에서 실행되므로, 해당 객체에 구성된 기존 정책 및 감사가 경로 내에 그대로 유지됩니다. LLM이 답변을 구성해야 할 때, AI 프로필(AI Profiles)이 있는 Select AI를 사용하면 모델이 볼 수 있는 범위를 지정하고 실행 전에 생성된 SQL을 검사할 수 있습니다.

그 결과, 대화형 사용이 가능할 만큼 충분히 빠르면서도 이미 운영 중인 것과 동일한 거버넌스(governance) 하에서 검토 가능한 검색 경로가 만들어집니다.

그림 1 — 데이터베이스 내부 RAG를 위한 Route → act → trust. 검색은 SQL이며, 거버넌스는 경로 내에 유지됩니다.

5번 아티클을 읽으셨다면 AI Profiles가 어떻게 NL2SQL(자연어를 SQL로 변환)을 검사 가능한 상태로 유지하는지 확인하셨을 것입니다. 본 아티클은 검색(retrieval)에 초점을 맞춥니다. 즉, 벡터(vectors)를 저장하는 방법, HNSW 또는 IVF 중 무엇을 선택할지, 그리고 리뷰 회의에서 방어할 수 있는 하이브리드 쿼리(hybrid queries)를 작성하는 방법을 다룹니다.

사전 요구 사항

Oracle AI Database 26ai 또는 사용 중인 RU/서비스 티어에서 AI Vector Search가 활성화된 Autonomous Database.
충분한 할당량(quota)이 있는 스키마에서 CREATE TABLE 및 CREATE INDEX를 수행할 수 있는 권한.
외부 임베딩(embeddings) 또는 Select AI를 사용하는 경우, 조직의 정책에 따라 자격 증명(credentials) 및 네트워크 ACL을 구성하십시오.
빌드 자동화 전에 해당 RU에서 CREATE VECTOR INDEX 옵션과 DBMS_* 패키지 서명(signatures)을 확인하십시오.

Oracle에서 "벡터 네이티브(vector-native)"의 의미

벡터 네이티브(Vector-native)란 임베딩(embeddings)이 사이드카(sidecar)가 아닌, 데이터베이스의 일급 객체(first-class) 데이터임을 의미합니다. 청크(chunked)된 콘텐츠와 출처(provenance)를 보유하는 테이블에 VECTOR(dim, element_type) 컬럼을 추가하고, 대화형 회상(interactive recall)을 위한 HNSW 또는 매우 큰 코퍼스(corpora)를 위한 IVF와 같은 근사 최근접 이웃(ANN, approximate nearest-neighbor) 인덱스를 구축한 뒤 SQL로 쿼리합니다.

실질적인 효과는 거버넌스의 연속성(governance continuity)입니다. 관련 객체에 가상 프라이빗 데이터베이스(VPD, Virtual Private Database) 정책, 통합 감사(Unified Auditing), 데이터 마스킹(Data Redaction), 투명한 데이터 암호화(TDE, Transparent Data Encryption)가 구성되어 있으면, 이러한 기능들이 검색 경로를 계속해서 필터링, 기록, 마스킹 및 보호합니다. 누군가 특정 행이 왜 컨텍스트 창(context window)에 들어갔는지 묻는다면, 다른 모든 쿼리를 관리하는 것과 동일한 테이블 범위 정책(table-scoped policies)을 가리킬 수 있습니다.

아키텍처 및 보안 세부 정보에 대해서는 Oracle AI Vector Search 개요와 VPD, 통합 감사 (Unified Auditing), 데이터 마스킹 (Data Redaction), TDE에 대한 데이터베이스 보안 가이드를 참조하십시오:

문서에서 청크로, 그리고 임베딩 (embeddings)으로

RAG의 품질은 사용자가 제어할 수 있는 두 가지 선택 사항, 즉 청크 (chunks)를 어디서 자를 것인지와 이를 어떻게 임베딩 (embed)할 것인지에 크게 좌우됩니다. Oracle은 크기와 중첩 (overlap)을 조정할 수 있는 결정론적 청킹 (deterministic chunking)을 위해 DBMS_VECTOR_CHAIN 유틸리티를 제공하므로, 반복 작업을 수행할 때 동일한 문서가 항상 동일한 방식으로 분할됩니다. 임베딩 (embeddings)의 경우, 데이터베이스 내부 모델을 실행하거나 (설치된 모델에 대한 DBMS_VECTOR 지원 및 해당 RU에 대해 문서화된 ONNX 참조), 데이터베이스에 저장되고 네트워크 ACL에 의해 관리되는 자격 증명을 사용하여 외부 제공업체를 호출할 수 있습니다. 이러한 결정 사항들을 의도적으로 업데이트할 수 있는 버전 관리된 선호 사항으로 취급하십시오.

저장 구조를 단순하게 유지하십시오: 청크당 하나의 행을 생성하고, 콘텐츠, 이미 보유하고 있는 출처 정보 (소스, 타임스탬프, 테넌트), 그리고 임베딩 (embedding)을 위한 VECTOR 컬럼을 포함합니다. 이러한 단일 행 설계는 하이브리드 검색 (hybrid retrieval)을 간단하게 만듭니다. 왜냐하면 적격성 여부는 WHERE 절로, 의미론적 유사성 (semantic similarity)은 ORDER BY로 처리되어 모두 하나의 문장에서 이루어지기 때문입니다.

문서:

DBMS_VECTOR (임베딩/모델 지원) [https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/dbms_vector1.html]
DBMS_VECTOR_CHAIN (청킹 및 임베딩 헬퍼) [https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/dbms_vector_chain1.html]

DBMS_HYBRID_VECTOR: 키워드 + 의미론적 유사성을 한 번에 처리

DBMS_VECTOR_CHAIN과 DBMS_VECTOR는 순수 벡터 워크플로우를 처리합니다. 하지만 검색 과정에서 전체 텍스트 키워드 일치(full-text keyword matching)—용어 빈도에 따른 관련성 순위 지정, Oracle Text lexer 규칙, 또는 다국어 토큰화—가 필요할 때, DBMS_HYBRID_VECTOR는 이 계층을 추가합니다. 이 패키지는 JSON 기반의 SEARCH API를 제공하며, 하이브리드 벡터 인덱스를 대상으로 키워드와 벡터 모두로 검색합니다. 전통적인 키워드 기반 텍스트 검색과 벡터 기반 유사성 검색을 단일 호출에 통합함으로써, 어느 한 가지 접근 방식만으로는 관련 결과를 놓칠 수 있는 쿼리의 재현율(recall)을 향상시킬 수 있습니다.

DBMS_HYBRID_VECTOR를 사용해야 하는 경우:

코퍼스에 품질이 혼합된 글쓰기가 포함되어 있을 때 (짧은 쿼리에는 정확한 키워드가 중요하고, 의역된 쿼리에는 의미론적 유사성이 중요할 때).
Oracle Text가 이미 처리하는 다른 어간 추출 규칙을 가진 여러 언어를 지원해야 할 때.
별도의 텍스트 및 벡터 결과 세트를 수동으로 병합하는 대신 단일 관리형 검색 API를 원할 때.

비즈니스 술어 필터링이 적용된 순수 벡터 검색의 경우, 아래 섹션에 있는 WHERE + VECTOR_DISTANCE 패턴이 더 간단하고 충분합니다. DBMS_HYBRID_VECTOR는 키워드 재현율(keyword recall)이 코퍼스에서 결과를 의미 있게 개선하는 경우로 제한하여 사용해야 합니다—더 복잡한 경로를 확정하기 전에 둘 다 측정해 보세요.

문서:

DBMS_HYBRID_VECTOR https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/dbms_hybrid_vector1.html

인덱스 선택: HNSW 또는 IVF

HNSW와 IVF 모두 1초 미만의 최근접 이웃 (nearest-neighbor) 검색을 제공하지만, 메모리, 구축 시간 및 재현율 (recall) 측면에서 서로 다른 트레이드오프 (trade-off)를 가집니다.

HNSW는 인메모리 (in-memory) 탐색 가능한 스몰 월드 그래프 (small-world graph)를 구축합니다. 실제로 HNSW는 코퍼스 (corpus) 크기와 이웃 차수 (neighbor degree)에 따라 증가하는 메모리 사용량을 대가로, 대화형 워크로드에서 낮은 지연 시간 (latency)과 높은 재현율 (recall)을 제공하는 경우가 많습니다. 인덱스를 구축하기 전에 DBMS_VECTOR에 문서화된 메모리 및 정확도 어드바이저 (advisors)를 사용하여 인덱스 풀 (index pool)의 크기를 결정하고 코퍼스에 대한 재현율을 검증하십시오. 쿼리가 조각조각 들어오고 정확도를 중시하는 고객 센터, 런북 (runbooks) 또는 내부 지식 베이스를 운영하는 경우 HNSW가 일반적인 시작점입니다. 데이터에 맞춰 측정하고 튜닝하십시오.

IVF는 벡터 공간을 파티션 (partitions)으로 클러스터링 (clustering)하고 쿼리당 일부 서브셋 (subset)만 조사 (probe)합니다. 이러한 설계는 메모리 사용량을 낮추고 매우 큰 코퍼스에서 좋은 처리량 (throughput)을 유지할 수 있습니다. 일부 재현율 (recall)을 희생하는 대신, 조사할 파티션의 수를 변경하여 이를 조정할 수 있습니다. 수백만 개의 청크 (chunks)와 꾸준한 트래픽을 관리하는 경우, Oracle의 정확도 및 성능 어드바이저를 사용하여 IVF를 운영 측면에서 평가하십시오.

실행 계획 (plans)과 기대치에 중요한 옵티마이저 (optimizer) 세부 사항이 하나 있습니다. 옵티마이저는 쿼리의 거리 측정 방식 (distance metric)이 인덱스의 측정 방식과 일치할 때만 벡터 인덱스를 사용합니다. 두 방식이 다르면 인덱스가 사용되지 않고 정확한 검색 (exact search)이 수행됩니다. 임베딩 (embeddings)에 코사인 유사도 (cosine similarity, 텍스트의 경우 일반적임)를 사용하는 경우, DISTANCE COSINE으로 인덱스를 생성하고 ORDER BY에서도 동일한 측정 방식을 사용하십시오.

Docs:

CREATE VECTOR INDEX (HNSW/IVF) [https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/create-vector-index.html]
DBMS_VECTOR advisors and accuracy helpers [https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/dbms_vector1.html]

방어할 수 있는 하이브리드 검색 작성하기 (Writing hybrid retrieval you can defend)

Oracle에서 하이브리드 검색은 그저 SQL입니다. 테넌트, 소스 시스템, 게시 날짜, 접근 수준과 같은 비즈니스 조건(business predicates)은 WHERE 절의 일반 필터이며, VECTOR_DISTANCE가 의미적 유사성(semantic similarity)에 따라 적격 행(eligible rows)을 순위화합니다. 이것이 단일 테이블과 단일 행 구조에서 발생하기 때문에, 실행 계획(execution plan)은 유사성을 위한 벡터 인덱스와 필터를 위한 기존 인덱스를 결합할 수 있습니다. 관련 객체에 구성되면, VPD 정책(VPD policies)은 여전히 세션에 적용됩니다.

전형적인 쿼리는 다음과 같습니다:

SELECT id, source, content
FROM   documents
WHERE  source = 'kb'
...

인덱스의 DISTANCE 메트릭이 쿼리의 메트릭과 일치하는지 확인해야 합니다. 그렇지 않으면 벡터 인덱스가 사용되지 않을 수 있습니다.

운영 환경에서 예상치 못한 상황을 방지하기 위해 알아야 할 두 가지 작은 세부 사항이 있습니다. VECTOR_DISTANCE는 더 가까운 벡터에 대해 더 작은 값을 반환하므로, 오름차순으로 정렬하고 메트릭을 명시적으로 유지하여 인덱스와 일치시켜야 합니다. 또한, 쿼리 벡터의 차원(dimension)과 요소 유형(element type)은 열(column)과 일치해야 하며 그렇지 않으면 구문 오류가 발생합니다. 계획에서, 종종 벡터 인덱스가 유사성 순서 지정(similarity ordering)을 만족시키고 B-트리(B‑trees) 또는 파티션이 필터를 만족시키는 것을 볼 수 있습니다. 옵티마이저의 선택은 조건자 선택도(predicate selectivity), 통계 정보(statistics), 그리고 메트릭/인덱스 정렬에 따라 달라집니다.

연산자 구문 (operator syntax)을 선호한다면, 26ai에서는 <=> 연산자가 코사인 거리 (cosine distance) 연산자입니다. 대상 버전의 문서에 해당 내용이 명시된 경우에만 사용하십시오. 그렇지 않다면 VECTOR_DISTANCE(..., COSINE)를 명시적으로 사용하는 것을 권장합니다:

SELECT id, source, content
FROM   documents
ORDER  BY embedding <=> :qvec
...

문서: