Cortex Search¶
개요¶
Cortex Search를 사용하면 Snowflake 데이터에서 지연 시간이 짧은 고품질의 “퍼지” 검색을 수행할 수 있습니다. Cortex Search는 대규모 언어 모델(LLMs)을 활용하는 Retrieval Augmented Generation (RAG) 애플리케이션을 비롯하여 Snowflake 사용자를 위한 다양한 검색 환경을 지원합니다.
Cortex Search를 사용하면 임베딩, 인프라 유지 관리, 검색 품질 매개 변수 조정 또는 연속 인덱스 새로 고침에 대해 걱정할 필요 없이 몇 분 만에 텍스트 데이터에 대한 하이브리드(벡터 및 키워드) 검색 엔진을 구축하고 실행할 수 있습니다. 즉, 인프라와 검색 품질 조정에 소요되는 시간을 단축하고, 데이터를 활용해 고품질 채팅 및 검색 환경을 개발하는 데 더 많은 시간을 할애할 수 있습니다. AI 채팅 및 검색 애플리케이션을 강화하기 위해 Cortex Search를 사용하는 방법에 대한 단계별 지침은 Cortex Search 자습서 를 참조하십시오.
Cortex Search를 사용하는 시점¶
Cortex Search의 두 가지 주요 사용 사례는 RAG(retrieval augmented generation) 및 엔터프라이즈 검색입니다
LLM 챗봇용 RAG 엔진: 의미 체계 검색을 활용하여 사용자 지정, 상황에 맞는 응답을 제공함으로써 텍스트 데이터로 채팅 애플리케이션을 위한 RAG 엔진으로 Cortex Search를 사용할 수 있습니다.
엔터프라이즈 검색: Cortex Search를 애플리케이션에 내장된 고품질 검색창의 백엔드로 사용할 수 있습니다.
RAG용 Cortex Search¶
RAG(Retrieval augmented generation)는 기술 자료에서 데이터를 검색하여 대규모 언어 모델의 생성된 응답을 향상시키는 기술입니다. 다음 아키텍처 다이어그램은 Cortex Search와 Cortex LLM 함수 를 결합하여 Snowflake 데이터를 기술 자료로 사용하여 RAG가 적용된 엔터프라이즈 챗봇을 구축하는 방법을 보여줍니다.

Cortex Search는 대규모 언어 모델에 최신 독점 데이터에 기반한 답변을 반환하는 데 필요한 컨텍스트를 제공하는 검색 엔진입니다.
예¶
이 예제에서는 Cortex Search Service를 구축하고 REST API를 사용하여 쿼리하는 단계를 안내합니다. 서비스 쿼리에 대한 자세한 내용은 Cortex Search Service 쿼리하기 항목을 참조하십시오.
이 예제에서는 고객 지원 기록 데이터 세트 샘플을 사용합니다.
다음 명령을 실행하여 예제 데이터베이스와 스키마를 설정합니다.
CREATE DATABASE IF NOT EXISTS cortex_search_db;
CREATE OR REPLACE WAREHOUSE cortex_search_wh WITH
WAREHOUSE_SIZE='X-SMALL';
CREATE OR REPLACE SCHEMA cortex_search_db.services;
다음 SQL 명령을 실행하여 데이터 세트를 생성합니다.
CREATE OR REPLACE TABLE support_transcripts (
transcript_text VARCHAR,
region VARCHAR,
agent_id VARCHAR
);
INSERT INTO support_transcripts VALUES
('My internet has been down since yesterday, can you help?', 'North America', 'AG1001'),
('I was overcharged for my last bill, need an explanation.', 'Europe', 'AG1002'),
('How do I reset my password? The email link is not working.', 'Asia', 'AG1003'),
('I received a faulty router, can I get it replaced?', 'North America', 'AG1004');
Cortex Search Service를 구축하려면 변경 사항을 추적해야 합니다. 이 테이블의 소유권이 없는 역할을 사용하여 검색 서비스를 구축하려면 다음 문을 실행하여 테이블에서 변경 내용 추적을 활성화합니다.
ALTER TABLE support_transcripts SET
CHANGE_TRACKING = TRUE;
변경 추적을 활성화하는 방법에 대한 자세한 내용은 변경 내용 추적 활성화 섹션을 참조하십시오.
서비스 생성¶
단일 SQL 쿼리로 또는 Snowflake AI & ML Studio에서 Cortex Search Service를 구축할 수 있습니다. Cortex Search Service를 생성하면 Snowflake가 소스 데이터에 대한 변환기를 수행하여 지연 시간이 짧은 서비스를 제공할 수 있도록 준비합니다. 다음 섹션에서는 SQL과 Snowsight 의 Snowflake AI & ML Studio를 모두 사용하여 서비스를 구축하는 방법을 설명합니다.
참고
검색 서비스를 생성하면 검색 인덱스가 생성 프로세스의 일부로 빌드됩니다. 즉, 데이터 세트가 큰 경우 CREATE CORTEX SEARCH SERVICE 문을 완료하는 데 시간이 더 오래 걸릴 수 있습니다.
SQL 사용하기¶
다음 예제에서는 이전 섹션에서 만든 샘플 고객 지원 기록 데이터 세트에 CREATE CORTEX SEARCH SERVICE 를 사용하여 Cortex Search Service를 구축하는 방법을 보여 줍니다.
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
ON transcript_text
ATTRIBUTES region
WAREHOUSE = cortex_search_wh
TARGET_LAG = '1 day'
AS (
SELECT
transcript_text,
region,
agent_id
FROM support_transcripts
);
이 명령은 데이터에 대한 검색 서비스 구축을 트리거합니다. 이 예제에서:
서비스에 대한 쿼리는
transcript_text
열에서 일치하는 항목을 검색합니다.
TARGET_LAG
매개 변수는 Cortex Search Service가 하루에 한 번 정도 기본 테이블support_transcripts
의 업데이트를 확인하도록 지정합니다.
region
및agent_id
열은 인덱스화되어transcript_text
열에 대한 쿼리 결과와 함께 반환될 수 있습니다.
transcript_text
열을 쿼리할 때region
열을 필터 열로 사용할 수 있습니다.
cortex_search_wh
웨어하우스는 처음에 지정된 쿼리의 결과를 구체화할 때와 기본 테이블이 변경될 때마다 사용됩니다.
참고
쿼리에 지정된 웨어하우스의 크기와 테이블의 행 수에 따라 이 CREATE 명령을 완료하는 데 최대 몇 시간이 걸릴 수 있습니다.
Snowflake는 각 서비스에 대해 MEDIUM 크기 미만의 전용 웨어하우스를 사용하는 것을 권장합니다.
ATTRIBUTES 필드의 열은 명시적 열거형 또는 와일드카드(
*
)를 통해 소스 쿼리에 포함되어야 합니다.
Snowsight 사용하기¶
다음 단계에 따라 Snowsight 에서 Cortex Search Service를 생성합니다.
Snowsight 에 로그인합니다.
SNOWFLAKE.CORTEX_USER 데이터베이스 역할이 부여된 역할을 선택합니다.
탐색 메뉴에서 AI & ML » Studio 를 선택합니다.
Create a Cortex Search Service 상자에서 + Create 를 선택합니다.
역할과 웨어하우스를 선택합니다. 역할에는 SNOWFLAKE.CORTEX_USER 데이터베이스 역할이 부여되어야 합니다. 웨어하우스는 서비스가 생성되고 새로 고쳐질 때 소스 쿼리의 결과를 구체화하는 데 사용됩니다.
서비스가 정의된 데이터베이스와 스키마를 선택합니다.
서비스 이름을 입력한 후 Let’s go 를 선택합니다.
검색을 위해 인덱싱할 텍스트 데이터가 포함된 테이블 또는 뷰를 선택한 다음 Next 를 선택합니다. 이 예제에서는
support_transcripts
테이블을 선택합니다.참고
서비스를 정의할 때 여러 데이터 소스를 지정하거나 변환기를 수행하려면 SQL을 사용 합니다.
검색 결과
transcript_text
,region
,agent_id
에 포함할 열을 선택한 다음 Next 를 선택합니다.검색할 열
transcript_text
를 선택한 다음 Next 를 선택합니다.특정 열을 기준으로 검색 결과를 필터링하려면 해당 열을 선택한 다음 Next 를 선택합니다. 필터가 필요하지 않으면 Skip this option 을 선택합니다. 이 예제에서는 이 단계를 건너뛸 수 있습니다.
서비스 콘텐츠가 기본 데이터 업데이트보다 지연되어야 하는 시간인 목표 지연 시간을 설정한 다음 Create search service 를 선택합니다.
마지막 단계에서는 서비스가 생성되었는지 확인하고 서비스 이름과 데이터 소스를 표시합니다.
참고
Snowsight 에서 서비스를 생성하면 서비스 이름이 큰따옴표로 묶입니다. SQL로 서비스를 참조할 때의 의미에 대한 자세한 내용은 큰따옴표로 묶인 식별자 섹션을 참조하십시오.
사용 권한 부여¶
서비스와 인덱스가 생성된 후에는 customer_support와 같은 다른 역할에 서비스, 해당 데이터베이스 및 스키마에 대한 사용 권한을 부여할 수 있습니다.
GRANT USAGE ON DATABASE cortex_search_db TO ROLE customer_support;
GRANT USAGE ON SCHEMA services TO ROLE customer_support;
GRANT USAGE ON CORTEX SEARCH SERVICE transcript_search_service TO ROLE customer_support;
서비스 미리 보기¶
서비스가 데이터로 올바르게 채워졌는지 확인하려면 SQL 환경에서 SEARCH_PREVIEW 함수 를 통해 서비스를 미리 볼 수 있습니다.
SELECT PARSE_JSON(
SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
'cortex_search_db.services.transcript_search_service',
'{
"query": "internet issues",
"columns":[
"transcript_text",
"region"
],
"filter": {"@eq": {"region": "North America"} },
"limit":1
}'
)
)['results'] as results;
성공적인 샘플 쿼리 응답:
[
{
"transcript_text" : "My internet has been down since yesterday, can you help?",
"region" : "North America"
}
]
이 응답은 해당 서비스가 데이터로 채워져 있고 주어진 쿼리에 대해 적절한 결과를 제공하고 있음을 보여줍니다.
애플리케이션에서 서비스 쿼리하기¶
검색 서비스를 생성하고, 역할에 사용 권한을 부여하고, 미리 본 후에는 이제 Python API 를 사용하여 애플리케이션에서 검색 서비스를 쿼리할 수 있습니다.
다음 코드는 Python API를 사용하여 North America
에 대한 쿼리와 가장 관련성이 높은 지원 티켓을 검색하고, internet issues
리전의 결과를 반환하도록 필터링하는 방법을 보여줍니다.
from snowflake.core import Root
from snowflake.snowpark import Session
CONNECTION_PARAMETERS = {"..."}
session = Session.builder.configs(CONNECTION_PARAMETERS).create()
root = Root(session)
transcript_search_service = (root
.databases["cortex_search_db"]
.schemas["services"]
.cortex_search_services["transcript_search_service"]
)
resp = transcript_search_service.search(
query="internet issues",
columns=["transcript_text", "region"],
filter={"@eq": {"region": "North America"} },
limit=1
)
print(resp.to_json())
성공적인 샘플 쿼리 응답:
{
"results": [
{
"transcript_text": "My internet has been down since yesterday, can you help?",
"region": "North America"
}
],
"request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}
Cortex Search Service는 쿼리의 columns
필드에 지정된 모든 열을 반환합니다.
필수 권한¶
Cortex Search Service를 생성하려면 역할에 Cortex LLM 함수에 필요한 CORTEX_USER 데이터베이스 역할이 있어야 합니다. 이 역할 부여 및 취소에 대한 자세한 내용은 Cortex LLM 함수 필수 권한 섹션을 참조하십시오.
Cortex Search Service를 쿼리하려면 쿼리하는 사용자의 역할이 서비스 자체와 서비스가 위치하는 데이터베이스 및 스키마에 대한 USAGE 권한을 가지고 있어야 합니다. Cortex Search 액세스 제어 요구 사항 섹션을 참조하십시오.
ALTER 명령을 사용하여 Cortex Search Service를 일시 중단하거나 다시 시작하려면 쿼리하는 사용자의 역할에 서비스에 대한 OPERATE 권한이 있어야 합니다. ALTER CORTEX SEARCH SERVICE 섹션을 참조하십시오.
Cortex Search 품질 이해하기¶
Cortex Search는 검색 및 순위 모델의 조합을 활용하여 조정이 거의 또는 전혀 필요 없는 높은 수준의 검색 품질을 제공합니다. Cortex Search는 기본적으로 문서를 검색하고 순위를 매기는 “하이브리드” 방식을 사용합니다. 각 검색어에는 다음이 활용됩니다.
의미 체계가 유사한 문서를 검색하는 벡터 검색.
어휘적으로 유사한 문서를 검색하는 키워드 검색.
결과 세트에서 가장 관련성이 높은 문서의 순위를 재조정하기 위한 의미 체계 순위 재지정.
이 하이브리드 검색 방법은 의미 체계 순위 재지정 단계와 결합되어 광범위한 데이터 세트와 쿼리에서 높은 검색 품질을 달성합니다.
토큰 제한 및 텍스트 분할¶
최적의 검색 결과를 얻으려면 Cortex Search에서 검색 열의 텍스트를 512개 이하의 토큰(영어 단어 약 385개) 청크로 분할하는 것이 좋습니다. 검색 열의 항목에 512개가 넘는 토큰이 포함된 경우 Cortex Search는 텍스트 본문 전체에 대해 키워드 기반 검색을 수행하지만 의미 체계(즉, 벡터 기반) 검색에는 처음 512개 토큰만 사용합니다.
토큰은 일련의 문자이며 대규모 언어 모델이 처리할 수 있는 가장 작은 단위입니다. 대략적으로 토큰 하나는 영어 단어의 약 3/4, 즉 약 4개 문자에 해당합니다. 문자열에 포함된 토큰의 정확한 개수를 계산하려면 다음과 같이 TOKEN_COUNT Cortex 함수 를 snowflake-arctic-embed-m
모델 매개 변수와 함께 사용하면 됩니다.
SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count
의미 체계 검색 토큰 제한 이해하기¶
512개 토큰 이하의 청크에 대한 권장 사항은 일반적으로 청크 크기가 작을수록 검색 및 다운스트림 LLM 응답 품질이 높아진다 는 연구 결과에 근거한 것입니다. 현재 arctic-embed-m-long 과 같은 긴 컨텍스트 임베딩 모델을 사용할 수 있지만, Cortex Search는 기본적으로 더 높은 검색 품질을 제공하기 위해 더 작은 컨텍스트 창이 있는 임베딩 모델을 선택합니다.
이 개념의 기본 개념은 청크가 작을수록 주어진 쿼리에 대해 더 정확하게 검색할 수 있다는 것입니다. 그 이유는 청크와 쿼리에 대한 벡터 임베딩을 생성할 때 “평균”을 계산할 토큰이 적기 때문입니다. 또한, 청크가 작아지면 모델에 대한 프롬프트에서 시끄러울 수 있는 텍스트가 줄어들기 때문에 다운스트림 LLM에 필요한 정보만 제공할 수 있습니다.
여기 에서 공용 Q&A 스타일의 벤치마크 데이터 세트에서 일반적으로 작은 청크가 더 나은 성능을 보인다는 연구 결과를 확인할 수 있습니다.
새로 고침¶
Cortex Search Service에서 제공되는 콘텐츠는 특정 쿼리의 결과를 기반으로 합니다. Cortex Search Service의 기반 데이터가 변경되면 해당 서비스가 업데이트되어 변경 사항을 반영합니다. 이러한 업데이트를 새로 고침 이라고 합니다. 이 프로세스는 자동화되어 있으며 테이블의 기반이 되는 쿼리를 분석하는 작업을 포함합니다.
Cortex Search Services는 동적 테이블과 동일한 새로 고침 속성을 갖습니다. Cortex Search Service의 새로 고침 특성을 이해하려면 동적 테이블 새로 고침 이해하기 항목을 참조하십시오.
Cortex Search Service의 소스 쿼리는 동적 테이블 증분 새로 고침의 후보여야 합니다. 해당 요구 사항에 대한 자세한 내용은 증분 새로 고침 지원 섹션을 참조하십시오. 이러한 제한은 벡터 임베딩 계산과 관련된 원치 않는 비용 급증을 방지하기 위해 고안되었습니다. 동적 테이블 증분 새로 고침에 지원되지 않는 구성에 대한 자세한 내용은 지원되지 않는 구문, 연산자 및 함수 섹션을 참조하십시오.
인덱싱 및 서비스 중단¶
Cortex Search Services는 동적 테이블과 마찬가지로 소스 쿼리와 관련된 새로 고침 실패가 5번 연속 발생하면 인덱싱 상태를 자동으로 일시 중단합니다. 서비스에서 이 오류가 발생하면 DESCRIBE CORTEX SEARCH SERVICE 또는 CORTEX_SEARCH_SERVICES 뷰 를 사용하여 특정 SQL 오류를 확인할 수 있습니다. 두 명령의 출력에는 다음 열이 포함됩니다.
INDEXING_STATE 열의 값은 SUSPENDED가 됩니다.
INDEXING_ERROR 열에는 소스 쿼리에서 발생한 특정 SQL 오류가 포함됩니다.
루트 문제가 해결되면 ALTER CORTEX SEARCH SERVICE <이름> RESUME INDEXING
로 서비스를 재개할 수 있습니다. 자세한 구문은 ALTER CORTEX SEARCH SERVICE 섹션을 참조하십시오.
비용 고려 사항¶
Cortex Search Service는 다음과 같이 비용이 발생합니다.
비용 카테고리 |
설명 |
---|---|
AI 서비스 - 서비스 비용 |
Cortex Search Service는 사용자가 제공하는 가상 웨어하우스와는 별도로 멀티테넌트 서비스 컴퓨팅을 사용하여 지연 시간이 짧은 검색 쿼리를 지원합니다. 컴퓨팅 비용은 인덱스된 데이터의 월 GB당(GB/월) 발생하며, 여기서 인덱스된 데이터는 Cortex Search 소스 쿼리의 사용자 제공 데이터와 사용자를 대신하여 계산된 벡터 임베딩을 의미합니다. 서비스 청구 계산에서 사용량은 2차 수준에서 측정되며, 한 달에 30.5일을 가정합니다. 바이트 단위로 인덱스된 데이터 크기는 대략 계정의 각 Cortex Search Service에 대한 시간당 서비스 토큰 소비량을 제공하는 CORTEX_SEARCH_SERVING_USAGE_HISTORY 뷰 에서 Cortex Search 제공 비용을 확인할 수 있습니다. Cortex Search 서비스 비용은 METERING_HISTORY 뷰 의 AI_SERVICES 총액에 추가로 포함됩니다. 인덱스 데이터의 월당 GB 크레딧 비용은 Snowflake 서비스 사용 테이블 을 참조하십시오. |
AI 서비스 - 임베딩 비용 |
Cortex Search Services는 SNOWFLAKE.CORTEX.EMBED_TEXT_768 LLM 함수를 사용하여 검색 열의 각 문서서를 벡터 공간에 포함시키며, 포함된 토큰당 크레딧 비용이 발생합니다. 임베딩은 소스 쿼리 평가에서 점진적으로 처리되므로 임베딩 비용은 추가되거나 변경된 문서에 대해서만 발생합니다. 벡터 임베딩 비용에 대한 자세한 내용은 벡터 임베딩 섹션을 참조하십시오. |
가상 웨어하우스 컴퓨팅 |
Cortex Search Service에는 사용자가 제공하는 가상 웨어하우스가 필요합니다. 이 웨어하우스는 사용자가 서비스를 생성할 때와 서비스가 새로 고쳐질 때마다 비용이 발생합니다. |
저장소 |
Cortex Search Service는 소스 쿼리를 사용자의 계정에 저장된 테이블로 구체화합니다. 이 테이블은 지연 시간이 짧은 서비스 제공을 위해 최적화된 데이터 구조로 변환되어 사용자 계정에 저장됩니다. 테이블 및 중간 데이터 구조의 저장소는 테라바이트(TB)당 정액제를 기반으로 합니다. |
클라우드 서비스 컴퓨팅 |
Cortex Search Service는 클라우드 서비스 컴퓨팅을 사용하여 기본 오브젝트가 변경되었을 때 새로 고침을 트리거합니다. 클라우드 서비스 컴퓨팅 비용은 일일 클라우드 서비스 비용이 계정의 일일 웨어하우스 비용의 10%보다 큰 경우에만 Snowflake가 요금을 청구하는 제약 조건을 따릅니다. |
팁
Snowflake는 Cortex Search Service에 MEDIUM을 초과하는 웨어하우스 크기를 사용하지 않는 것을 권장합니다. 이 권장 사항은 향후 제품 업데이트로 인해 향후에 적용되지 않을 수 있습니다.
알려진 제한 사항¶
Cortex Search의 사용에는 다음과 같은 제한이 적용됩니다.
지원 언어: 이 기능은 영어로 된 문서 및 쿼리에 최적화되어 있습니다.
기본 테이블 크기: 최적의 서비스 성능을 유지하려면 검색 서비스의 구체화된 쿼리 결과의 행 크기가 5,000만 개 미만이어야 합니다. 쿼리의 구체화된 결과에 5,000만 개를 초과하는 행이 있는 경우 생성 쿼리에서 오류가 발생합니다.
참고
Cortex Search Service의 행 크기 조정 한도를 5,000만 개 이상으로 늘리려면 Snowflake 계정 팀에 문의하십시오.
쿼리 구성: Cortex Search Service 소스 쿼리는 동적 테이블과 동일한 쿼리 제한을 준수해야 합니다. 자세한 내용은 동적 테이블의 알려진 제한 사항 섹션을 참조하십시오.
데이터베이스 복제 및 스키마 복제: Cortex Search Services는 데이터베이스 복제 또는 스키마 복제 를 지원하지 않습니다. 이러한 기능에 대한 지원은 향후 릴리스에서 제공될 예정입니다.
중요
사용자가 생성하는 각 Cortex Search에 대해 동적 테이블에 대한 Snowsight 모니터링 UI 에 표시되는 2개의 동적 테이블 엔터티가 있습니다. 이러한 두 엔터티는 _CORTEX_SEARCH_SOURCE_*
및 _CORTEX_SEARCH_REFRESH_*
의 형식을 갖습니다. 이러한 엔터티는 Dynamic Table 정보 스키마 뷰에도 표시되지만, Dynamic Tables SHOW/DESC 명령에는 표시되지 않습니다. Snowsight UI에서 이러한 엔터티 중 하나를 클릭하면 Dynamic Table not found
메시지가 표시됩니다. 이는 예상되는 동작입니다. 향후 제품 릴리스에서 Cortex Search 관련 엔터티는 Snowsight Dynamic Tables Monitoring UI에서 제거될 예정입니다.
리전 가용성¶
이 기능에 대한 지원은 다음 Snowflake 리전의 계정에서 사용할 수 있습니다.
AWS |
Azure |
GCP |
---|---|---|
US 서부 2(오리건) |
동부 US 2(버지니아) |
유럽 서부 2(런던) |
US 동부 2(오하이오) |
중남부 US(텍사스) |
유럽 서부 3(프랑크푸르트) |
US 동부 1(북부 버지니아) |
UK 남부(런던) |
유럽 서부 4(네덜란드) |
캐나다(중부) |
북유럽(아일랜드) |
US 중부(아이오와) |
남미(상파울루) |
서부 유럽(네덜란드) |
US 동부 4(북부 버지니아) |
유럽(아일랜드) |
스위스 북부(취리히) |
|
유럽(런던) |
인도 중부(푸네) |
|
유럽 중부 1(프랑크푸르트) |
일본 동부(도쿄, 사이타마) |
|
유럽(스톡홀름) |
동남아시아(싱가포르) |
|
아시아 태평양(도쿄) |
호주 동부(뉴사우스웨일즈) |
|
아시아 태평양(뭄바이) |
||
아시아 태평양(시드니) |
||
아시아 태평양(자카르타) |
||
아시아 태평양(서울) |
법적 고지¶
입력 및 출력의 데이터 분류는 다음 테이블과 같습니다.
입력 데이터 분류 |
출력 데이터 분류 |
지정 |
---|---|---|
Usage Data |
Customer Data |
Covered AI Features [1] |
자세한 내용은 Snowflake AI 및 ML 섹션을 참조하십시오.