Knowledge base match at intake

Operators often spend the opening minutes of a ticket hunting for a similar case, a known workaround, or a documented procedure. A knowledge base match step shortens that hunt by retrieving candidate articles from an existing corpus and attaching them to the intake record before the operator opens it.

The match is a retrieval aid, not a resolution. Using retrieval-augmented generation (RAG), the agent queries known solutions against the new request and writes the best candidates onto the record as operator context. It does not close the ticket, apply a fix, or treat a high similarity score as confirmation that the article is correct for this instance.

This is most useful when the same class of issue arrives with different wording each time: a repeated access error, a fulfillment exception, a device fault with a known workaround. It is also useful when the person on the queue is new and does not yet know which article to open. The value is time-to-context, not automated close.

Related intake work often runs next to this step. Unstructured request parsing turns free-text channels into searchable fields. Auto-classification by type assigns a request type. SLA pre-tag from request content proposes a service target. Knowledge base match uses the same request text, and sometimes those derived fields, as query context. It does not replace those steps.

Two inputs are required: a request the retriever can search against, and a knowledge base that can be queried.

The request must exist as text. That usually means a subject, a parsed body, and any structured fields already extracted at intake. An empty form, an encrypted attachment, or a screenshot with no transcript is not enough. If the inbound message has not been parsed yet, run parsing first so retrieval is not searching a blob of noise.

The knowledge base must exist as a corpus the agent is allowed to search. Typical sources are internal solution articles, standard operating procedures, approved workarounds, and closed-ticket write-ups that operations has promoted into the index. A shared drive that nobody indexed is not a knowledge base for this step. If the corpus is missing, unreachable, or has zero documents in the collection the queue is allowed to use, the agent returns empty output. It must not invent an article from model memory and attach it as if it came from the corpus.

Optional context can improve ranking without becoming a hard requirement. Request type, product, site, customer segment, and language help the retriever prefer articles that match the queue. Keep those filters conservative. Over-filtering on a guessed type can hide the article that actually applies. When type is uncertain, search the broader corpus and let rank plus operator review do the narrowing.

Permissions are part of the input contract. Attach only articles the operator is allowed to open. A match from a restricted runbook that the queue cannot read is worse than no match, because it looks like help and fails when the operator clicks through.

The agent writes candidates onto the intake record as a list, not as a single chosen answer. Each item should be inspectable: article identifier, title, a short passage that justified the match, a link or internal path, and enough ranking metadata for the operator to see why it appeared.

Keep the list short. A handful of candidates is enough for intake. A long dump of weakly related pages recreates the search problem this step is meant to avoid. Prefer a relevance floor over a forced top-k that always fills the panel.

Attachment is additive. The original request stays intact. Matched articles sit in a dedicated field or related-records panel so they can be accepted, dismissed, or ignored without editing customer text. If a later re-parse changes the request body, the match step can run again and replace the candidate list. It should not silently rewrite operator notes or resolution text.

If the generation side of RAG is used at all, keep it narrow. A one-line reason for each candidate (for example, that it mentions the same error code and product family) helps the operator scan. A synthesized how-to that mixes several articles into a new procedure is out of scope for intake match. Mixing sources at this stage hides provenance and makes it harder to tell which document actually applied.

Do not auto-apply the top article as the resolution. Rank is a retrieval signal. It is not confirmation that the article is current, approved, or correct for this instance. Currency still belongs to the knowledge base owners. Retrieval should prefer the indexed, approved version of an article, not an outdated copy sitting in a side folder.

Human-in-the-loop is the control point. RAG attaches candidate articles. The operator decides whether they apply.

Review is a short, explicit check. Open the top candidates. Confirm the article describes the same product, condition, and constraint as the request. Check that it is still the approved path, not a retired workaround. If it applies, use it as the starting procedure and record which article was used. If it is close but not quite right, keep it as background and continue investigating. If none apply, dismiss the candidates so the next person does not treat a near-miss as a known fix.

False matches are expected. Shared error strings, generic phrasing such as "cannot log in," and overlapping product names will surface articles that look related and are not. The operator's job is to reject those, not to trust the rank order. False negatives happen too. A well-written article may use different vocabulary than the customer. When the operator knows a better article exists, they should attach it manually. That correction is useful later for corpus and query tuning. The intake page should not wait on a training loop before the operator can act.

The record should show the decision. Accepted article, dismissed candidates, or no applicable knowledge are all valid outcomes. Leaving candidates attached without a decision is acceptable while the ticket is still being triaged. Closing the ticket as solved solely because an article was attached is not. Applicability is a human judgment about this request, not a property of the similarity score.

The correct output is empty when either required input is missing.

If there is no request text the retriever can use, return no candidates. Do not attach a generic getting-started article to fill the panel. If the knowledge base is missing, empty, or the query cannot run, return no candidates. Do not generate a plausible-sounding solution from the model and present it as a knowledge article.

Empty output is also correct when retrieval runs and finds nothing above a minimum relevance threshold. Forced filler trains operators to ignore the panel. Prefer a blank related-articles list and a visible no-matches state over low-quality pages that happen to share a few tokens.

Other failure modes should fail closed. Index outage, permission errors, and timeouts should yield empty candidates and a system note that match was skipped, not a partial list that looks complete. If parsing produced unusable fields, do not query on those fields. Wait for usable text or skip the step.

Logging should distinguish three states: not run, run with no hits, and run with candidates attached. Those states are what operations needs when reviewing whether the step is helping a queue, and when deciding whether a blank panel was a healthy miss or a broken index.

Knowledge base match is one intake enrichment among several. Parsing gives the retriever clean text. Classification can optionally scope the corpus. SLA pre-tag still depends on request content and policy, not on whether a known article exists. A matched runbook does not change the clock by itself. If an article implies a different severity or target, the operator can adjust the SLA tag. The agent should not silently override it.

A practical order is parse first, then classify and retrieve in close sequence, then present the intake record as a bundle: structured fields, proposed type, proposed SLA, and candidate articles. The operator reviews that bundle once. Splitting the knowledge search into a later, separate hunt is what this step is meant to avoid.