# ICM The **Settings > Configuration > ICM** section contains tenant-level settings for the Intent Classification Model (ICM), the service responsible for classifying user intents within the bot framework. These settings control how ICM preprocesses requests, scores and ranks intent candidates, and extracts key strings from compound queries. Changes apply across all bots in your tenant. ### Enable Incremental Retrain | **Type** | Checkbox | | ----------- | -------- | | **Default** | Disabled | When enabled, ICM model retraining updates only the utterances that have changed since the last training run, processing new utterances into the model and removing deleted ones. If no changes are detected, ICM skips the retrain entirely. When disabled, every training run rebuilds the model completely from scratch. Enable this when your intent library is large and well-established, and training is triggered frequently by small incremental changes. Leave it disabled for initial model builds, major intent taxonomy restructuring, or when troubleshooting model quality issues. {% hint style="info" %} If incremental training fails for any reason, the system automatically falls back to a full retrain. {% endhint %} ## Request preprocessing ### Remove HTML | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | Strips HTML tags from user queries before ICM processes them for intent classification. ICM preserves tag content, removing only the tags themselves. If stripping the tags would leave the message empty, ICM keeps the original message as a fallback. Leave this enabled for most deployments. Disable it only if incoming requests intentionally contain HTML markup that should be matched as plain text. {% hint style="info" %} This applies to incoming user queries at prediction time only. It does not affect how utterances are stored or trained. {% endhint %} ### Enable Coreference Resolution | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | Preprocesses user requests to replace pronoun and demonstrative references, including "it," "its," "this," "that," "these," "those," and "both," with the explicit terms they refer to before intent classification runs. This helps the classifier correctly identify intent when users refer back to previously mentioned topics using shorthand. Requests that contain none of these words pass through unchanged. When disabled, classification runs on the original request text as-is. Keep this enabled when users frequently refer to previously mentioned topics using pronouns or demonstratives. Disable it if the resolver is producing incorrect rewrites that are degrading classification accuracy. ## Intent scoring and matching ### Semantic Search threshold | **Type** | Decimal | | ----------- | ------- | | **Default** | `0.75` | Sets the minimum similarity score a semantic intent match must achieve to be returned as a candidate during ICM prediction. ICM discards matches scoring below this threshold before surfacing results. ICM rescales candidates at or above the threshold before passing them to the rest of the pipeline. Raise this value if your tenant is receiving too many low-confidence or irrelevant semantic intent matches. Lower it if legitimate intents are being missed, particularly when user phrasing varies significantly from trained utterances. {% hint style="info" %} ICM processes requests through multiple classifiers. This threshold applies to the semantic classifier only and has no effect on keyword or entity-based matching. Changes to this value affect both how many results are returned and how those results are scored downstream. {% endhint %} ### Use Balanced Scoring Metric | **Type** | Checkbox | | ----------- | -------- | | **Default** | Disabled | Changes how the keyword-based classifier scores intent matches. When disabled, a candidate intent is scored by how much of the trained utterance's words appear in the user's query, which can cause short or generic utterances to score disproportionately high against longer queries. When enabled, scoring blends two directions in a 60/40 ratio: how much of the utterance matches the query, and how much of the query matches the utterance. This penalizes cases where a short utterance technically matches but covers only a small fraction of what the user actually said. Enable this if short or partial utterances are producing unexpectedly high-confidence matches against longer user queries. {% hint style="info" %} This setting applies only to the keyword-based classifier. It has no effect on semantic matching. {% endhint %} ### Score Window Size | **Type** | Decimal | | ----------- | ------- | | **Default** | `0.05` | Defines a score band below the top-scoring intent within which ICM retains all other candidates for further processing. After all classifiers have scored intent candidates, ICM keeps every intent whose score falls within this value of the highest-scoring result. For example, if the top intent scores `0.85` and the window size is `0.05`, all intents scoring `0.80` or above are passed downstream for disambiguation or the **Number of Intents** limit. ICM drops intents scoring below that band. Increase this value if closely-scoring intents are being dropped before disambiguation can surface them. Decrease it if too many lower-confidence intents are passing through alongside the best match. ### Number of Intents | **Type** | Integer | | ----------- | ------- | | **Default** | `3` | No description available. ### Drop Casual if Request contains Entities | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | Removes casual intent matches from results when the user's request contains a recognized named entity. Casual intents are non-actionable interactions, such as greetings, that have no service action behind them. If ICM detects at least one entity in the request, it drops all casual intents from the candidate list before returning results. This check runs on each scored sub-string as well as the full request. This setting suits most tenants. A request containing a named entity is almost always task-oriented, making a casual intent match unlikely to be the correct result. ### All Slots Required To Hit Utterance | **Type** | Checkbox | | ----------- | -------- | | **Default** | Disabled | Controls how strictly the keyword-based classifier matches training utterances that contain slot variables. Slot variables are placeholders in a training utterance that represent specific pieces of information to be extracted from a request, for example `{application}` in "reset my {application} password." When disabled, the classifier considers an utterance a match candidate if at least one of its slot variables appears in the user's request. When enabled, the classifier must detect every slot variable in the utterance for it to qualify. Utterances without slot variables pass through unchanged. Enable this when partial slot matches are causing incorrect intent classifications, particularly when your intents have training utterances with two or more slot variables. ### Use Only Non-Overlapping Entities For Scoring | **Type** | Checkbox | | ----------- | -------- | | **Default** | Disabled | Controls which entity detections the keyword-based classifier uses when multiple entity models detect overlapping spans in the same request. When disabled, the classifier uses all detected entity matches for scoring, including cases where multiple entities cover the same text span. When enabled, the classifier uses only the winning entity match per span, producing stricter and more selective scoring. For example, in the request "I can't open Microsoft Office," one parser might detect "Microsoft" (vendor) and "Office" (product) as separate entities, while another detects "Microsoft Office" as a single application entity. When disabled, all three detections contribute to scoring, which can cause utterances trained on `[vendor] [product]` and utterances trained on `[app]` to both score well against the same input. When enabled, only "Microsoft Office" survives as the winning span, so only utterances trained on `[app]` receive credit for that detection. Enable this when overlapping entity detections are causing false intent matches or inflating match scores. It is most relevant for tenants with complex entity schemas where multiple entity types can recognize the same portion of a request. ## Key-string extraction (KSE) ### Enable Key-String Extraction (KSE) | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | Breaks a request into meaningful sub-strings before classification, allowing each part of a compound request to be scored independently. When enabled, KSE parses a request containing conjunctions, prepositions, or punctuation into ranked sub-strings. For example, "reset my password and unlock my account" becomes two separate strings, each classified independently with results merged into the final output. When disabled, classifiers process the full request text as a single unit. Requests without conjunctions, prepositions, or punctuation are never split regardless of this setting. Keep this enabled when users frequently submit complex or multi-part requests in a single message. Disable it if sub-string splitting is causing fragmentation that degrades classification accuracy. ### Use Embeddings (KSE) | **Type** | Checkbox | | ------------ | ---------------------------------- | | **Default** | Enabled | | **Requires** | Enable Key-String Extraction (KSE) | Controls whether Key-String Extraction uses semantic scoring to prioritize the sub-strings it extracts from a request. When enabled, KSE ranks sub-strings by their relevance to the original request before passing them to classifiers. When disabled, KSE ranks sub-strings by structural features alone. Keep this enabled to ensure the most relevant sub-strings are classified first. Disable it only if latency is a concern and a structural ranking is sufficient for your request patterns. ### Number of Strings (KSE) | **Type** | Integer | | ------------ | ---------------------------------- | | **Default** | `7` | | **Requires** | Enable Key-String Extraction (KSE) | Sets the maximum number of ranked sub-strings that Key-String Extraction passes to intent classifiers. Higher values provide more coverage for complex requests at the cost of additional classifier calls and latency; lower values reduce latency but may miss intent in highly compound requests. The standard setting suits most tenants. Increase it if intent is being missed in long or highly compound requests; decrease it to reduce classification latency. ### Parse Phrases (KSE) | **Type** | Checkbox | | ------------ | ---------------------------------- | | **Default** | Enabled | | **Requires** | Enable Key-String Extraction (KSE) | Controls whether Key-String Extraction breaks compound sentences into individual phrase segments before classification. When enabled, KSE uses syntactic analysis to extract sub-clauses from a request in addition to the full sentence. For example, "My VPN isn't connecting and my email isn't syncing" produces "My VPN isn't connecting" and "my email isn't syncing" as separate strings, each of which can match its respective intent independently. When disabled, only the full sentence is passed to classifiers, which may not closely match either intent in training data. Keep this enabled when users frequently bundle multiple requests into a single sentence. Disable it if phrase-level extraction is producing overly fragmented strings that reduce classification accuracy. ### Time Budget | **Type** | Decimal | | ------------ | ---------------------------------- | | **Default** | `1.0` | | **Requires** | Enable Key-String Extraction (KSE) | Sets the maximum total time in seconds that intent classifiers are permitted to spend processing key strings for a single request. After processing each key string, ICM checks elapsed time against this value. If the cumulative time across all classifiers exceeds the limit, the current classifier stops and ICM skips remaining lower-ranked key strings. The budget is cumulative across all classifiers for a single request, not per individual classifier. At minimum, one key string is always processed per classifier regardless of the budget. The standard limit suits most tenants. Reduce it if classification latency exceeds your response time requirements; increase it if complex or compound requests are being cut short before all relevant key strings are classified. {% hint style="info" %} This setting has no effect when Enable Key-String Extraction (KSE) is disabled. Without KSE, classifiers process the full request as a single unit with no time-budget check. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.aisera.com/aisera-platform/tenant-setup/aisera-platform-configuration/tenant-configuration-settings/icm.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.