Match Queries
Match Queries🔗
Match queries are auto-generated queries based on an input document (document URI) or URL.
Matching based on an already indexed document🔗
When matching based on an already indexed document, use the following query language to construct the document URI:
doc://environmentName/searchEngine/documentID/[extractorName].
Example: doc://mycompany_cv/mycandidates/12345/extractor1
The components of the URI are described below. Consult Textkernel Support for the correct values to use in your match queries.
| URI Component | Description |
|---|---|
| environmentName | The name of the environment in which the source document is located. You will receive an error if you try to reference an environment that you do not have access to. |
| searchEngine | The name of the searcher (within the environment) in which the source document is located. |
| documentID | The ID of the source document. |
| extractorName | Optional. The name of the query extractor in the target environment. Different query extractors can be used for different Match query templates. By default, the target environment's default query extractor is used. |
Match Fingerprint🔗
Auto-generated Match queries may contain a special fingerprint to improve the relevance of the Match results. The text_fingerprint captures important nuances from the source document (candidate or job profile). It boosts results containing salient keywords over results containing only common keywords.
The text_fingerprint is never displayed in the Search UI. In case the user manually removes all visible query parts one-by-one so that the text_fingerprint is the only remaining query part, it is automatically removed from the query.
Match Pre-Filtering🔗
Match query results are getting pre-filtered by default. If a query is recognized as being a Match query, we create and apply an additional filter component, independent of the condition types of the query parts. Hence, even with only nice-to-have and should-have query parts, results that make no chance to be relevant are filtered out from the result set. Match pre-filtering is based on 3 components of the query:
- the job title
- the normalized job group ID
- the skills
Only if a query contains all 3 components a Match pre-filter is created and applied. This will filter out results that doesn't match ANY of the 3 components. In case of the skills, only a reasonable fraction of the requested skills needs to be matched in order to satisfy this component. For that, we first consider only the skill-field having the most query parts in the Match query, being either professional skills or computer skills. Then, the number of required skills of that skill field to regard this component matching is determined. For a query having less than 4 skills it's just 1, for less than 7 it's 2, and for any higher number we request at least 3 matching skill parts. (Notice, that the skill component of the filter is only to allow also for results that satisfy neither jobtitle nor jobgroup.)
Currently, the following Match fields are recognized for the different components:
| Component | Field Names |
|---|---|
| job title | jobtitlesonlyrecent, recent_jobtitles, vacancytitle, jobtitle |
| job group | jobgroupidsonlyrecent, recent_profession_groups, profession_group |
| skills | compskills, profskills |