Google Cloud Search에는 검색 결과에 영향을 주는 여러 기본 확장, 해석, 최적화가 있습니다. 검색어에서 예기치 않은 결과가 표시되면 Cloud Search 지원팀에 문의하기 전에 이 가이드를 참고하세요.
기본 확장
사용자가 [Joe의 PDF]와 같은 문자열을 사용하여 검색하는데 반환된 일부 결과에 'PDF' 대신 '문서'와 같은 단어가 강조 표시되어 있다고 가정해 보겠습니다. 검색어에 없었던 단어가 강조 표시된 이유는 무엇인가요?
기본적으로 Google Cloud Search는 Google 웹 검색과 마찬가지로 쿼리의 정확한 단어만 검색하지 않습니다. 대신 Cloud Search는 동의어와 어근을 포함하도록 쿼리를 확장합니다 (자체 동의어를 구현하지 않은 경우에도). 이 확장은 쿼리의 아이디어와 의도에 광범위하게 일치하는 문서를 검색하기 위해 실행됩니다. 이 광범위한 문서 세트가 선택되면 순위 알고리즘이 최적의 일치 항목이 결과 세트의 상단에 배치되도록 합니다.
사용자가 [Joe’s PDFs]를 검색하면 Cloud Search에서 다음과 같은 허용 가능한 단어를 추가로 제공했습니다.
[Joe's]의 경우 Cloud Search에서 'joe' (어간 확장) 및 'joes' (구두점에 기반한 동의어)도 일치할 수 있습니다.
[PDF]의 경우 Cloud Search에서 '문서' (동의어 확장) 및 'pdf' (어간 확장)도 일치시킬 수 있습니다.
기본적으로 동의어는 양방향이 아닐 수 있습니다. 예를 들어 사용자가 '피싱'이라는 용어를 검색하면 Cloud Search에서 '피시'를 동의어 확장으로 매칭할 수 있습니다. 하지만 사용자가 '피시'라는 용어를 검색하면 Google에서 '피싱'을 확장으로 매칭하지 않을 수 있습니다.
하이픈이 있는 단어와 하이픈이 없는 단어의 확장
사용자가 하이픈이 있는 단어와 하이픈이 없는 단어를 검색하는 경우(예: [walk-in closet] 및 [walk in closet]) Cloud Search에서는 이러한 쿼리를 다르게 처리합니다.
또한 [walk-in] 및 [walk_in]과 같이 하이픈과 밑줄이 있는 단어에는 서로 다른 최적화가 사용됩니다.
기본 확장 보상
기본적으로 확장이 보장되지 않습니다. 동의어 또는 도메인별 동의어 확장의 양방향성을 보장하려면 자체 도메인별 동의어 집합을 만드세요. 동의어 구현에 관한 자세한 내용은 동의어 정의를 참고하세요.
기본 해석
Cloud Search는 특정 데이터 소스에 업로드된 스키마에 따라 쿼리에 사용된 객체, 속성, 필드 값을 해석하는 자연어 해석도 제공합니다. 이 자연어 해석에 관한 자세한 내용은 검색어 해석 최적화를 위한 스키마 구조화를 참고하세요.
[null,null,["최종 업데이트: 2025-08-29(UTC)"],[],[],null,["# Compensate for default expansions, interpretations, and optimizations\n\nGoogle Cloud Search has several default expansions, interpretations, and\noptimizations that affect search results. If ever you are seeing unexpected\nresults from search queries, refer to this guide before contacting Cloud Search\nsupport.\n| **Note:** The example queries in this document are shown in square brackets to set them apart from words specified in quotes representing Google's interpretation of the query.\n| **Note:** The query results in this document don't represent guarantees of product behavior. Instead, the results shown in this document provide insight of how expansions, interpretations, and optimizations work.\n\nDefault expansions\n------------------\n\nSuppose a user is searching using a string, such as \\[Joe's PDFs\\], but\nsome returned results contain highlighted words, such as \"documents,\" instead of\n\"PDFs.\" Why do the results contain the highlighted words that weren't in the\nsearch query?\n\nBy default, Google Cloud Search, just like Google Web Search, doesn't only\nsearch for the exact words in a query. Instead Cloud Search expands the query\nto include synonyms and word stems (even if you haven't implemented your own\nsynonyms). This expansion is done to retrieve documents that broadly match the\nidea and intent of the query. After this broad set of documents is selected, the\nranking algorithms work to ensure that the best matches are placed at the top of\nthe result set.\n\nWhen the user searched for \\[Joe's PDFs\\], Cloud Search supplied the following as\nadditional acceptable words:\n\n- For \\[Joe's\\], Cloud Search might also match \"joe\" (a stem expansion) and \"joes\" (a synonym based on punctuation).\n- For \\[PDFs\\], Cloud Search might also match \"documents\" (a synonym expansion) and \"pdf\" (a stem expansion).\n\nBy default, synonyms are not necessarily bi-directional. For example, if a user\nsearches for the term \"phishing,\" Cloud Search might match \"phish\" as a synonym\nexpansion. However if the user searches for the term \"phish,\" Google might not\nmatch \"phishing\" as an expansion.\n\n### Expansions for hyphenated versus non-hyphenated words\n\nWhen the user searches for hyphenated words versus their non-hyphenated\nequivalents, such as \\[walk-in closet\\] and \\[walk in closet\\], Cloud Search\ntreats these queries differently.\n\nAdditionally, different optimizations are used for hyphenated and underscored\nwords, such as \\[walk-in\\] and \\[walk_in\\].\n\n### Compensate for default expansions\n\nThere is no guarantee of any expansion by default. If you want to\nensure bidirectionality of synonyms or domain-specific synonym expansions,\ncreate your own set of domain-specific synonyms. For further information on\nimplementing synonyms, refer to\n[Define synonyms](/workspace/cloud-search/docs/guides/synonyms).\n| **Note:** It is important to educate your users on the use of quotes for exact matching, either as options in your search interface or in your documentation. For example, instead of searching for \\[Joe's PDFs\\], search for \\[Joe's \"PDFs\"\\], where \"PDFs\" is in quotes, to return documents that exactly match the word \"PDFs.\"\n\nDefault interpretations\n-----------------------\n\nCloud Search also provides natural-language interpretation which\ninterprets the objects, properties, and field values used in a query according\nto the schema uploaded for a particular data source. For further information\nabout this natural-language interpretation, refer to\n[Structure your schema for optimal query interpretation](/workspace/cloud-search/docs/guides/query-interpretation).\n\n### Disable natural-language interpretations\n\nTo disable natural-language interpretations for a specific query, set\n[`QueryInterpretationOptions.disableNlInterpretation`](/workspace/cloud-search/docs/reference/rest/v1/query/search#queryinterpretationoptions)\nto `true` in the search request.\n\nDefault optimizations\n---------------------\n\nCloud Search provides these default optimizations as well:\n\n- Blending in results provided by spelling correction. For example, if the query\n string was \\[corpoate benefits\\], Cloud Search would match \"corpoate\" and the\n correct spelling of \"corporate.\"\n\n | **Note:** When a user incorrectly spells a word in a query, the query's response might contain a suggested spelling in the [`SpellResult`](/workspace/cloud-search/docs/reference/rest/v1/query/search#spellresult) field. Although the systems providing spelling and synonyms results are separate, the synonyms system might provide a correct spelling as a synonym for an incorrect spelling. For example, the user searches for \\[procss\\] and receives \"process\" as a synonym. The `SpellResult` field is only populated in the case of an actual spell correction.\n- For queries that would yield zero or few results, Cloud Search uses a more\n permissive set of related terms, broader than direct synonyms, when matching\n results. For further information, refer to\n [Handle supplemental results](/workspace/cloud-search/docs/guides/query-guide#display_query_results).\n\nNormalizing documents and queries\n---------------------------------\n\nNormalizing refers to standardizing on certain words or phrases either prior to\nor after a query has been made. To ensure more consistent responses to your\nqueries, consider normalizing your documents (prior to or during indexing) and\nqueries (after the user has made the query) in the following ways:\n\n- To normalize documents:\n\n 1. Pick a canonical spelling for critical words used in documents within your repositories.\n 2. Correct the spelling in source repository documents, or when indexing content, to match canonical spelling.\n- To normalize queries:\n\n 1. Intercept user queries before sending them to Cloud Search.\n 2. Rewrite words in user queries to match the most-common spelling in the indexed data source.\n 3. Send the query to Cloud Search.\n\nDisable expansions, interpretations, and optimizations for all queries\n----------------------------------------------------------------------\n\nTo disable expansions, interpretations and optimizations for a specific query,\nset\n[`QueryInterpretationOptions.enableVerbatim Mode`](/workspace/cloud-search/docs/reference/rest/v1/query/search#queryinterpretationoptions)\nto `true` in the search request."]]
