[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[],[],null,["# Search overview\n\nCloud Talent Solution allows users to search against jobs that you store\nin the Job Search index. Job Search is designed to be customizable and can be\naltered to meet your business needs. This page is an overview of the\nsearch functions available in CTS Job Search.\n\nMaking search requests\n----------------------\n\nTo make a Job Search request, send a POST request to the\n[`jobs:search`](/talent-solution/job-search/docs/reference/rest/v4/projects.tenants.jobs/search)\nendpoint, passing the search data in the body.\n\n### Commonly used fields (optional)\n\n- `JobQuery`: The `JobQuery` object consists of two components, a `query`\n string and the filter(s) applied to that string. This feature allows your\n users to search on a query string (such as \"communications assistant\") using\n one or more filters (location, commute time, compensation, and so on).\n See [Search Filters](/talent-solution/job-search/docs/search-filters) for\n more information and a list of available filter options.\n\n- `searchMode`: Specifies the type of search to apply. Options are:\n\n - `JOB_SEARCH` (recommended): This is the default search mode, which searches against all Job objects. The most relevant jobs are returned to the user in the order of relevance to the search query.\n - `FEATURED_JOB_SEARCH`: Searches only for Job objects with a `promotionValue` greater than 0. Results are ordered by the highest `promotionValue` first; in the case of a tie, relevance is used to decide position. See [Featured Jobs](/talent-solution/job-search/docs/featured-jobs) for more information.\n- `jobView`: Defines the number of fields that are returned for each\n matching Job object. Can be `JOB_VIEW_SMALL` (default), `JOB_VIEW_MINIMAL`,\n or `JOB_VIEW_FULL`. Descriptions for each option can be found in the\n [`JobView`](/talent-solution/job-search/docs/reference/rest/v4/JobView)\n reference documentation.\n\n- `orderBy`: The sort order for returned Jobs. See the\n [reference](/talent-solution/job-search/docs/reference/rest/v4/projects.tenants.jobs/search#body.request_body.FIELDS.order_by)\n documentation for allowed values. The default is to sort by relevance,\n descending (`RELEVANCE_DESC`).\n\n### Required fields\n\nThe following field is required:\n\n- `requestMetadata`: Contains user and session information for this search request.\n\n#### `RequestMetadata`\n\nEvery search and histogram request must include a\n[`RequestMetadata`](/talent-solution/job-search/docs/reference/rest/v4/RequestMetadata)\nobject. This object contains information about the user initiating the search.\nIt is important for two main reasons:\n\n- **User consistency** : Cloud Talent Solution runs several versions of the\n underlying models simultaneously to improve search relevance.\n CTS ensures that a job seeker (identified by\n [userId](/talent-solution/job-search/docs/reference/rest/v4/RequestMetadata#FIELDS.user_id), [sessionId](/talent-solution/job-search/docs/reference/rest/v4/RequestMetadata#FIELDS.session_id),\n and [domain](/talent-solution/job-search/docs/reference/rest/v4/RequestMetadata#FIELDS.domain)) has a\n consistent experience. These fields should be obfuscated.\n\n- **Search improvements** : The tuning algorithms are based on the information\n provided in the `RequestMetadata` fields along with the job seekers' data\n you provide. This improves search result relevance.\n\n### Using search operators\n\nThe search operators in the table below may be used alone or in combination.\n\n### Job seeker queries\n\nSearch terms can also be detected as actual Job-related entities. For example,\nif a user queries for \"intern\", Cloud Talent Solution treats this as the\nemployment type `INTERN` and filters on Jobs with the designation\n`EMPLOYMENT_TYPE - INTERN`. Therefore, even a Job object with \"intern\" in its\ndescription would not be returned if the `EMPLOYMENT_TYPE` field for that Job\nwas set to something else.\n| **Note:** It is very important to specify the employment type for each Job object. Not doing so negatively impacts the job seeker's experience.\n\nTroubleshooting\n---------------\n\nEach search request generates a unique search `requestID` in the Job Search\nsystem. This value is used to track the parameters of that search as well as the\nresponse. This is crucial in troubleshooting issues related to specific searches\nor CRUD requests, and should be appropriately logged. The `requestID` is\nreturned inside the\n[ResponseMetadata](/talent-solution/job-search/docs/reference/rest/v4/ResponseMetadata)\nfield in the [search response\nbody](/talent-solution/job-search/docs/reference/rest/v4/projects.tenants.jobs/search#response-body)\nor the associated CRUD call response object.\n\nFor support issues that relate to relevance, search inquiries, indexing\ninquiries, and so on, please [file a ticket](/talent-solution/docs/support)\nwith our support team and include relevant `requestID`s or the requests\nthemselves.\n\n### Diagnose data issues using the console\n\nUse the **Jobs and companies** page in the\n[CTS console](https://console.cloud.google.com/talent-solution)\nto diagnose issues around job data. If you need to troubleshoot data issues,\nyou view job statistics, search for metadata of specific jobs, and export\ndata by job, company, or tenant.\nSee the documentation section\n[Jobs and companies data](/talent-solution/job-search/docs/management-tools#job-data)\nfor more on how to use these tools.\n\nResult counts\n-------------\n\nThe result count is used to communicate the number of search results to the job\nseeker. This doesn't always correspond to the\n[histogram](/talent-solution/job-search/docs/histogram) results or the actual\nnumber of jobs returned. Job Search returns a maximum of 5000 jobs.\n\nPagination (optional)\n---------------------\n\nBy default, Job Search returns 100 results in a single call (or fewer, if the\ntotal number of results is less than 100). To view more than 100 results, you\ncan implement pagination. If the total number of results exceeds the maximum of\n5000, all pages after the page containing the 5000th result will be blank. The\nfields below control pagination:\n\n- **`pageSize`**: The number of results returned.\n- **`nextPageToken`**: A unique token, returned with the results of each page of search results, that specifies the starting position for the next page of results. This field is left empty if there are no more results.\n- **`offset`** : Specifies the offset between the relevance ranking of the job returned at the top of a given page and 1 (the most relevant Job returned). As an example, a user performs a search and `pageSize` is set to 10. The first page returns the #1 job at the top, therefore the `offset` value for this page is 0. The next page returns job #11 at the top; `offset` for this page is 10.\n\nThere are two main ways to implement pagination. You can use `pageSize` and\n`nextPageToken` to directly point to the next page of results (each page has\na new `nextPageToken` value that points to the subsequent page). If you use\nthis method you will always start at the top of the results and page through in\nsequential order. Alternatively, you can use `pageSize` with `offset` to\ndirectly specify which numbered result appears at the top of each page. Using\n`offset` instead of `nextPageToken` allows you to jump to any point in the\nresult set.\n\nWe recommend that you set the page size to 20 results or less to avoid latency\nissues. As a best practice, issue a separate search call per page\nrendered to the job seeker. The alternative, a single search call to return a\nlarger number of jobs and paginating on the client side, impedes\nthe ability of the machine learning model to learn accurately through the Jobs\nAnalytics Framework.\n\nIf you use pagination all fields in the request other than `pageSize`,\n`nextPageToken` and `offset` must remain the same. If these fields are not the\nsame the order of jobs returned in the results can be inconsistent.\n\nSpell checking\n--------------\n\nSpell check is an optional feature of a CTS search request\nIt accounts for potentially misspelled search terms, corrects them and returns\nresults based on the corrected query. For example, when spell check is enabled,\nif a job seeker searches for \"manaer\" instead of \"manager\",\nCTS returns jobs for \"manager\". Spell check can be\nenabled/disabled by setting the `disableSpellCheck` field of the search request.\nIf spell checking is enabled, the corrected query can be found in the search\nresponse, in the `spellResult` field."]]