이 페이지에서는 정형 데이터, 메타데이터가 포함된 비정형 데이터 또는 맞춤 구조화된 속성이 포함된 웹사이트 데이터용 앱을 설정하도록 스키마 필드를 구성하는 방법을 보여줍니다.
필드 설정을 사용하면 Agent Search가 결과에서 필드를 사용하는 방식을 결정할 수 있습니다.Google Cloud 콘솔의 스키마 탭을 사용하여 필드 설정을 구성할 수 있습니다.
필드 설정은 구조화된 데이터 또는 메타데이터가 있는 비정형 데이터가 포함된 데이터 스토어가 있는 앱에서만 구성할 수 있습니다.
필드 설정
다음 필드 설정은 검색 또는 추천 데이터의 여러 필드 유형에 사용할 수 있지만 일부 데이터 유형에는 사용할 수 없습니다. 스키마에는 개별 필드의 여러 필드 설정이 포함되어 있으며 다음 표에는 스키마 내 필드에 적용할 수 있는 설정이 포함되어 있습니다. 다음 필드 설정에는 구조화된 데이터를 사용하는 것이 좋습니다.
| 설정 | 정의 | 목적 | 사용 사례 예시 |
|---|---|---|---|
| 색인 생성 가능 | 필드를 색인 가능으로 설정하면 문서 내 구조화된 필드에서 필터링, 부스팅, 패싯과 같은 작업을 실행할 수 있습니다.
|
필드를 필드를 |
호텔 데이터 스토어에서 hotel_chain와 같은 필드를 색인 생성 가능으로 설정할 수 있습니다. 이렇게 하면 hotel_chain에 순위 지정, 필터링, 부스팅 작업을 적용할 수 있습니다. 예를 들어 필터링된 호텔 체인이 포함된 검색 결과만 표시되도록 필터를 적용할 수 있습니다. |
| 검색 가능 |
검색과 관련이 있을 가능성이 가장 높은 필드는 텍스트 값이 있는 필드만 검색 가능으로 표시할 수 있습니다. 따라서 숫자 가격 필드는 색인을 생성할 수 있지만 (필터링 또는 패싯용) 전체 텍스트로 검색할 수는 없습니다. |
필드를 검색 가능으로 설정하면 검색어에서 해당 필드의 재현율이 향상되어 사용자가 이러한 필드 내의 텍스트를 쿼리하여 웹페이지와 같은 콘텐츠를 찾을 수 있습니다. 필드를 검색 가능으로 표시하면 순위를 적용할 수 있습니다. 따라서 너무 많은 필드를 검색 가능으로 표시하면 순위 알고리즘이 과포화되어 너무 많은 결과가 반환되므로 검색 정확도에 부정적인 영향을 미칠 수 있습니다. 이로 인해 관련성이 없는 검색 결과가 반환될 수 있습니다. 검색 가능한 필드에 상대 가중치를 적용할 수 있지만, 강력한 기본값으로 인해 이 작업이 필요한 경우는 거의 없습니다. 아래의 가중치 검색 가능 필드를 참고하세요. |
인터넷 서비스 제공업체의 지원 티켓 시스템은 각 티켓을 구조화된 문서로 저장합니다. 이러한 문서에 |
| 접두사 일치 가능 (미리보기) |
필터 표현식에서 자세한 내용은 아래의 접두사 및 부분 일치에 사용할 수 있는 필드 만들기를 참고하세요. |
필드를 접두사 일치 가능으로 설정하면 검색엔진이 필드 값의 접두사인 쿼리 문자열을 일치시킬 수 있습니다. 이는 문자열의 시작이 알려진 계층적 식별자, 경로 또는 코드를 일치시키는 데 특히 유용합니다. 접두사 일치는 정규화된 필드 값의 처음 12자로 제한되며 검색 색인의 크기를 늘립니다. 10개 이상의 필드를 접두사 일치 가능으로 설정할 수는 없습니다. |
|
| 부분적으로 일치 (미리보기) |
필터 표현식에서 자세한 내용은 아래의 접두사 및 부분 일치에 사용할 수 있는 필드 만들기를 참고하세요. |
필드를 부분적으로 일치하도록 설정하면 필드 내에서 토큰 기반 일치가 가능해지므로 사용자가 필드 값의 일부만 알고 있는 경우에도 콘텐츠를 찾을 수 있습니다. 검색엔진은 순서에 관계없이 필드 값의 토큰과 쿼리 토큰을 일치시킵니다. 필드를 부분적으로 일치 가능으로 표시하면 검색 색인의 크기가 증가합니다. 부분 일치 가능으로 설정할 수 있는 필드는 10개를 초과할 수 없습니다. |
유럽의 지역을 필터링하려고 합니다. |
| 동적 패싯 생성 가능 | 사용자의 검색을 더 잘 타겟팅하기 위해 컨텍스트 인식 필터를 제공합니다. 필드를 Dynamic Facetable로 설정하면 시스템에서 필드에 있는 고유한 값을 기반으로 대화형 필터 (패싯)를 자동으로 생성할 수 있습니다. |
필드를 Dynamic
facetable로 설정하면 사용자가 가능한 모든 필터 옵션을 수동으로 사전 정의하지 않고도 수집된 데이터에서 직접 파생된 카테고리나 속성을 선택하여 검색 결과를 동적으로 세분화할 수 있습니다. 이를 통해 사용자는 검색을 매우 구체적인 웹 콘텐츠로 좁힐 수 있습니다.검색 가능과 함께 동적 패싯 가능을 사용하여 더 나은 결과를 얻을 수 있으며, 이는 검색의 재현율과 사용자에게 제공되는 패싯의 품질을 모두 개선합니다. |
HR 정책과 같은 내부 회사 지식 베이스의 페이지는 department, document_type, last_modified_date와 같은 데이터로 인제스트됩니다. 이러한 필드가 dynamic facetable로 태그된 경우 직원이 비용 상환과 같은 용어를 검색하면 관련 검색 결과를 기반으로 대화형 필터가 동적으로 생성됩니다. 이 경우 웹 인터페이스에 부서: 재무, 여행, 문서 유형: 정책, FAQ 또는 최근 수정 날짜: 이번 분기, 작년과 같은 패싯이 표시될 수 있습니다. |
| 가져오기 가능 | 검색어가 일치하는 콘텐츠에 도달하면 검색엔진은 검색 가능한 필드의 값을 가져와 표시하거나 애플리케이션에서 사용할 수 있습니다. 즉, 원본 문서의 정보가 검색 결과의 일부로 표시됩니다. 키 필드(문서의 고유 식별자)가 검색 가능으로 설정됩니다. | 검색 가능한 필드는 값이 표시될 수 있는 필드와 검색 로직에서만 사용되지만 원시 값은 최종 사용자에게 표시되지 않는 필드를 구분하여 검색 컨텍스트를 제공합니다. | 판매자 사이트의 제품 검색의 경우 product_id, name, price, image_url은 검색 가능으로 설정할 수 있는 일반적인 필드입니다. 반면 internal_tracking_code은 관리 목적으로만 색인이 생성되고 필터링될 수 있지만 공개 검색 결과에서는 검색할 수 없습니다. |
| 완성 가능 | 필드의 콘텐츠를 검색어 추천에 사용할 수 있습니다. 자세한 내용은 자동 완성 구성을 참고하세요. | 이 설정을 사용하면 사용자가 입력할 때 실시간 쿼리 추천을 제공하는 데 해당 필드의 값을 사용할 수 있습니다. 이 기능은 사용자를 관련 콘텐츠로 안내하고 검색 프로세스를 가속화합니다. 자연어 필터링 사용과 같은 특정 요인이 이 성능에 영향을 줄 수 있습니다. | completable 필드가 product_name, brand, category에 설정되어 있는 경우 사용자가 기술을 입력하면 자동 완성 추천에 다음이 표시될 수 있습니다.
|
| 필터링 가능 | 추천에서 필드를 사용하여 추천 결과를 필터링하여 사용자에게 표시되는 검색 결과를 결정할 수 있습니다. 추천 필터링에 대한 자세한 내용은 추천 필터링을 참고하세요. | 필드를 Filterable로 설정하면 사용자를 위한 추천을 맞춤설정할 수 있습니다. 필터링 한도가 적용됩니다. |
언어 및 드라마별 필터 설정은 language_code: ANY("en", "fr") OR categories: ANY("drama")와 같습니다. |
흔히 사용되는 설정 간의 차이점
색인 생성 가능, 검색 가능, 검색 가능 필드 설정 간에는 주요 차이점이 있습니다. 다음 표에 이러한 차이점이 요약되어 있습니다.
| 기능 | Indexable | 검색 가능 | 가져오기 가능 |
|---|---|---|---|
| 기본 역할 | 검색엔진에서 필드 콘텐츠를 사용할 수 있도록 합니다. | 필드 콘텐츠에 대한 전체 텍스트 쿼리를 허용합니다. | 필드의 값이 검색 결과에 반환되도록 허용합니다. |
| 분석 | 콘텐츠가 처리되어 색인에 추가됩니다. | 일반적으로 광범위한 어휘 분석을 거칩니다. | 값은 표시를 위해 있는 그대로 저장됩니다. |
| 이게... | |||
| ...검색 가능? | 예 (필수사항인 경우가 많음) | 해당 사항 없음 | 반드시 그런 것은 아닙니다 (검색할 수 없어도 검색 가능). |
| ...가져올 수 있나요? | 반드시 그런 것은 아님 | 반드시 그런 것은 아님 | 해당 사항 없음 |
| ...필터링/정렬/패싯 가능? | 예 (일반적으로 이러한 항목의 필수 요건이기도 함) | 직접적으로는 불가능합니다. 이러한 속성은 색인 생성 가능한 필드를 기반으로 구축되는 경우가 많습니다. | 직접적으로는 아닙니다. 이러한 속성은 필드가 표시되는 방식뿐만 아니라 필드가 색인 생성되고 쿼리되는 방식과 관련이 있습니다. |
실제로 사용자 경험에 중요한 많은 필드 (예: 제목, 설명, 식별 정보)는 indexable, searchable, retrievable로 설정되는 경우가 많습니다.
제한사항
필드 설정에는 다음과 같은 제한사항이 있습니다.
- 최대 50개의 필드를 색인 생성 가능, 검색 가능, 가져오기 가능 또는 동적 패싯 생성 가능으로 구성할 수 있습니다.
- 필드를 동적 패싯 생성 가능으로 구성하려면 먼저 색인 생성 가능으로 구성해야 합니다.
- 색인 생성 가능 설정을 변경하려면 데이터의 색인을 다시 생성해야 하므로 특히 대규모 데이터 스토어의 경우 몇 시간이 걸릴 수 있습니다.
미디어 검색 앱의 필드를 구성하는 경우 스키마의 필드에 대한 세부정보를 확인하려면 미디어 문서 및 데이터 스토어 정보를 참조하세요.
필드 설정 업데이트
필드 설정을 업데이트하려면 다음 단계를 따르세요.
Google Cloud 콘솔에서 AI 애플리케이션 페이지로 이동합니다.
수정하려는 앱의 이름을 클릭합니다.
데이터를 클릭합니다.
스키마 탭을 클릭합니다. 이 탭에는 현재 필드 설정이 표시됩니다.
데이터 스토어에 기본 웹사이트 데이터 또는 메타데이터가 없는 비정형 데이터가 포함된 경우 스키마 탭이 표시되지 않습니다.
수정을 클릭합니다.
업데이트해야 하는 필드 설정을 선택하거나 삭제합니다. 일부 필드 설정은 지원되지 않습니다. 예를 들어 숫자 필드는 검색 가능으로 설정할 수 없습니다.
저장을 클릭하여 변경사항을 적용합니다.
가중치 검색 가능 필드 (미리보기)
필드를 검색 가능으로 표시하면 검색 결과에서 필드의 상대적 중요도를 나타내는 가중치를 지정할 수 있습니다. 기본 가중치가 적합하므로 대부분의 상황에서 개별 필드의 가중치를 지정할 필요가 없습니다.
하지만 다음과 같은 몇 가지 상황에서는 가중치를 조정해야 할 수 있습니다.
가중치가 적용된 필드를 이미 사용하는 기존 검색 플랫폼에서 데이터를 이전합니다.
기본 가중치로 만족스러운 검색 결과를 얻을 수 없는 경우. 특히 검색 가능한 필드가 많고 일부 필드가 다른 필드보다 훨씬 더 중요한 경우에 발생할 수 있습니다.
요약이 검색에 가장 중요한 필드이므로 해당 텍스트에 우선순위를 지정할 수 있습니다.
또는 스키마에 검색 결과를 잘 예측하는 매우 관련성 높은 키워드가 포함된 필드가 있지만 이 필드가 다른 필드보다 훨씬 짧기 때문에 영향력이 긴 필드에 가려지는 경우가 있습니다. 가중치를 높이면 의도한 영향을 미칠 수 있습니다.
가중치 수준
가중치는 다음 수준으로 분류됩니다.
| 필드 중요도 | 설명 |
|---|---|
| 매우 낮음 | 시스템에서 모든 필드의 점수를 결합할 때 여전히 고려하는 낮은 값입니다. 효과가 미미하도록 가중치를 더 낮추려면 필드를 검색 가능으로 표시하지 마세요. |
| 낮음 | 기본값보다 낮은 가중치 |
| 기본 | 검색 가능한 필드의 표준 가중치입니다. 이 가중치는 대부분의 경우에 적절한 성능을 제공합니다. |
| 높음 | 기본값보다 눈에 띄게 높은 가중치 |
| 매우 높음 | 지배적인 가중치입니다. 일반적으로 이 속성은 최대 하나의 필드에만 사용됩니다. |
스키마 업데이트 및 색인 재작성
검색 가능한 필드에 가중치를 추가하려면 스키마를 업데이트하고 데이터 스토어의 데이터를 다시 색인해야 합니다. 스키마를 업데이트하는 데 몇 시간이 걸리며 색인이 완료되는 시점을 알려주는 신뢰할 수 있는 지표가 없으므로 색인 시간을 과대평가해야 합니다.
필드에 가중치 수준 설정
필드의 가중치 수준을 설정하는 작업은 작은 변경사항만 적용하고 의도하지 않은 결과가 있는지 검색 결과를 신중하게 검토해야 하므로 지루할 수 있습니다. 각 변경 후에는 변경사항의 영향을 평가하기 전에 색인 생성이 완료될 때까지 기다려야 합니다.
검색 필드 가중치는 API를 통해서만 구성할 수 있습니다. Google Cloud 콘솔에서는 이 기능을 사용할 수 없습니다.
가중치를 설정하려면 API projects.locations.dataStores.schemas.patch 메서드를 통해 데이터 스토어의 스키마를 업데이트해야 합니다.
스키마가 아직 없다면 스키마 정의 보기의 안내에 따라 스키마를 가져옵니다.
안내에 따라 프로그래매틱 방식으로 스키마를 업데이트합니다. 다음 예와 같이 하나 이상의 검색 가능한 필드에 가중치를 추가합니다.
"summary": { "type": "string", "searchable": true, "weight": "high" }, "uri": { "type": "string", "searchable": true, "weight": "low" },이 예에서는
summary필드가 일반보다 높은 가중치로 설정되고uri필드는 낮은 가중치로 설정됩니다. 가중치를 기본값으로 되돌리려면default로 설정합니다.가중치 매개변수에 허용되는 값은 다음과 같습니다.
very_lowlowdefaulthighvery_high
색인 생성이 완료될 때까지 기다린 후 검색 행동을 테스트합니다.
필드를 접두사 및 부분 일치에 사용할 수 있도록 설정 (미리보기)
string 유형의 필드의 경우 스키마를 수정하여 필드를 접두사 일치 또는 부분 일치에 사용할 수 있도록 할 수 있습니다. 이렇게 하면 필터 표현식에서 STARTS_WITH 또는 CONTAINS를 사용할 수 있습니다.
스키마 업데이트 및 색인 재작성
필드를 접두사 또는 부분 일치에 사용할 수 있도록 하려면 스키마를 업데이트하고 데이터 스토어의 데이터를 다시 색인해야 합니다. 스키마를 업데이트하는 데 몇 시간이 걸리며 색인이 완료되는 시점을 알려주는 신뢰할 수 있는 지표가 없으므로 색인 생성 시간을 과대평가해야 합니다.
접두사 및 부분 일치 스키마 업데이트
필드를 접두사 일치 또는 부분 일치에 사용할 수 있는 것으로 지정하려면 API projects.locations.dataStores.schemas.patch 메서드를 통해 데이터 스토어의 스키마를 업데이트해야 합니다.
스키마가 아직 없다면 스키마 정의 보기의 안내에 따라 스키마를 가져옵니다.
안내에 따라 프로그래매틱 방식으로 스키마를 업데이트합니다. 다음 예와 같이 스키마에서 일치 가능한 매개변수를
true로 설정합니다."zone": { "type": "string", "searchable": true, "prefixMatchable": true }, "region": { "type": "string", "searchable": true, "partialMatchable": true }, "model": { "type": "string", "searchable": true, "prefixMatchable": true, "partialMatchable": true },이 예시에서
zone필드는 접두사 일치 가능으로 설정됩니다. 필터 표현식에서 최대 12자(대소문자 구분 안 함)를 사용하여 필드 값을 일치시킬 수 있습니다.region필드가 부분적으로 일치하도록 설정됩니다.색인 생성이 완료될 때까지 기다립니다.
프리픽스 일치에 관한 세부정보
상담사 검색의 접두사 일치를 사용하면 필드의 값이 특정 문자열로 시작하는지 여부에 따라 결과를 필터링할 수 있습니다. 이 기능은 STARTS_WITH 연산자를 기반으로 하며, 타겟 텍스트 필드가 스키마에서 prefixMatchable로 구성되어야 합니다.
정규화 및 일치 논리
성능을 최적화하고 일관성을 유지하기 위해 시스템은 필드 값 (색인 생성 중)과 쿼리 문자열 (검색 중) 모두에 특정 정규화 프로세스를 적용합니다.
소문자 변환: 모든 문자가 소문자로 변환됩니다. 이렇게 하면 대소문자를 구분하지 않고 일치시킵니다.
12자 잘림: 시스템은 문자열의 처음 12자만 고려합니다. 이 한도를 초과하는 문자는 접두사 일치 목적으로 무시됩니다.
작동 방식
색인 생성 시 prefixMatchable로 표시된 필드의 경우 시스템은 처음 12개 문자에 대한 접두사 토큰을 생성합니다. asia-south1-c와 같은 값의 경우 색인은 a, as, asi, asia, asia- 등의 토큰을 최대 12번째 문자 (asia-south1-)까지 저장합니다.
쿼리 시 STARTS_WITH 연산자에 제공된 문자열도 소문자로 변환되고 12자로 잘립니다. 그런 다음 쿼리가 저장된 접두사 토큰과 일치하는지 확인합니다.
예시
다음 예에서는 12자 정규화가 검색 결과에 미치는 영향을 보여줍니다.
확장검색:
STARTS_WITH("A")는asia,australia,africa와 같이 'a'로 시작하는 모든 값과 일치합니다(대소문자 구분 안 함).부분 접두사:
STARTS_WITH("asia-south")는asia-south1-a및asia-southeast1-b와 모두 일치합니다. 두 단어 모두 지정된 10자리 문자열로 시작하기 때문입니다.잘림 동작: 처음 12자만 일치하므로
STARTS_WITH("asia-south1-a")는asia-south1-c필드 값과 일치합니다. 두 문자열이 모두 동일한 12자리 접두사(asia-south1-)로 정규화되기 때문에 이 문제가 발생합니다.
부분 일치에 대한 세부정보
상담사 검색의 부분 일치를 사용하면 필드의 값에 특정 단어나 토큰이 포함되어 있는지에 따라 결과를 필터링할 수 있습니다. 이 기능은 CONTAINS 연산자를 기반으로 하며, 타겟 텍스트 필드가 스키마에서 partialMatchable로 구성되어야 합니다.
정규화 및 토큰화 로직
상담사 검색은 필드 값(색인 생성 중)과 쿼리 문자열 (검색 중)을 모두 정규화하고 토큰화합니다.
소문자 변환: 상담사 검색에서 문자를 소문자로 변환합니다. 이렇게 하면 대소문자를 구분하지 않고 일치시킬 수 있습니다.
토큰화: 상담사 검색은 공백과 기타 문자를 구분 기호로 사용하여 문자열을 개별 토큰 (단어)으로 분할합니다.
표준 구분 기호: 공백과 일반적인 구두점은 구분 기호로 사용됩니다. 여기에는 하이픈 (
-), 슬래시 (/), 쉼표(,), 마침표 (.), 별표 (*), 중괄호 ({ }), 대괄호 ([ ]), 괄호 (( )), 아포스트로피 (')가 포함됩니다.비구분자: 앰퍼샌드 (
&)와 밑줄 (_)은 구분자로 작동하지 않습니다. 시스템은 이러한 기호로 연결된 문자를 단일 토큰으로 취급합니다.이메일 구분자 (
@):@기호는 이메일 주소를 인식하는 데 도움이 되는 특수 구분자 역할을 합니다. 시스템은 개별 구성요소와 결합된 형식의 토큰을 생성합니다. 예를 들어support+tier1@example.com을support,tier1,example,com,support+tier1@example.com,support@example.com으로 토큰화합니다.
작동 방식
색인 생성 시 partialMatchable로 표시된 필드의 경우 시스템은 필드 값을 정규화하고 토큰화하여 결과 토큰을 색인에 저장합니다. 예를 들어 25-meter, outdoor, swimming
pool 필드 값을 [25, meter, outdoor, swimming, pool]로 토큰화합니다.
쿼리 시 CONTAINS 연산자에 제공된 문자열은 동일한 정규화 및 토큰화 프로세스를 거칩니다. 그런 다음 검색 엔진은 결과로 생성된 모든 쿼리 토큰이 필드의 저장된 토큰과 일치하는지 확인합니다. 토큰의 순서는 중요하지 않습니다.
예시
다음 예에서는 토큰화가 부분 일치 결과에 미치는 영향을 보여줍니다.
기본 토큰 일치: 필드 값이
25-meter, outdoor, swimming pool인 경우CONTAINS("Outdoor pool")필터가 일치합니다. 시스템은[outdoor, pool]에 대한 쿼리를 토큰화하며, 둘 다 필드의 토큰에 있습니다.순서 독립성: 시스템에서 각 토큰의 존재를 순서와 관계없이 확인하므로
CONTAINS("pool outdoor")필터는25-meter, outdoor, swimming pool필드 값과도 일치합니다.이메일 주소 일치: 필드에 이메일
support+tier1@example.com이 저장되어 있는 경우@기호의 특수 토큰화로 인해CONTAINS("support"),CONTAINS("example.com")또는CONTAINS("support@example.com")과 같은 필터가 모두 성공적으로 일치합니다.