One of the biggest challenges with large outcome sets isn’t just maintaining them—it’s using them efficiently during inference. If you pass all 5,000 possible values into a prompt or system message, you’re not only inflating token usage, you’re also diluting model focus and increasing cost.

To solve this, we semantically pre-filter the options based on the context of the text being processed.

Instead of forcing the LLM to choose from everything—colors, sizes, issues, ingredients, styles, or product SKUs—we dynamically narrow the list to a semantically relevant subset. This keeps the prompt lightweight and focused, improving:

• ⚡ Speed: Fewer tokens means faster processing
• 💸 Cost: Reduced token usage lowers inference costs
• 🧠 Accuracy: Fewer distractions = better match selection
• 🎯 Relevance: Model focuses only on what matters for this specific input

This approach keeps the LLM’s attention where it needs to be—on picking the right outcome, not filtering through irrelevant ones.

With our latest update to the Extraction API and Assertion API, we’re introducing a new capability:
➡️ Semantic matching over external Descriptor, Descriptor Type and Item Type entities.

As a quick reminder, here’s how Item Types, Descriptor Types and finally Descriptors are structured within the platform:

Here’s an example of how they tie together when modeling a car:

Depending on your use case, you might need to find the best match for an Item Type, a Descriptor Type or a Descriptor.

✨ What’s New?

Instead of defining all enum values or validation outcomes inline, you can now:

• Store them in structured entities like Descriptor, Descriptor Type and Item Type
• Configure your extraction or assertion definitions to query these entities dynamically.
• Let the model find the most semantically appropriate match based on context.

This unlocks powerful use cases like:

• Matching fuzzy phrases in text to controlled vocabularies (e.g., “tangerine” → Orange)
• Classifying items into thousands of possible categories
• Adapting to business taxonomies without hardcoding them

🧪 Example: Assertion with Semantic Lookup

Let’s say you’re processing item descriptions and want to:

• Determine the item type
• Extract its most appropriate color

Rather than supplying a long list of types and colors manually, you reference existing descriptors:

{
  "assertionInstruction": "Pick the most appropriate color for the item",
  "outcomeSourceConfig": {
    "sourceEntityType": "descriptor",
    "filter": {
      "type-name": "item.attribute.color.name",
      "similarity-threshold": 0.1,
      "branch-id": "00000000-0000-0000-0000-000000000000"
    }
  }
}

✅ Sample Response

🧠 The system uses semantic similarity to match the description “tangerine” to a Descriptor labeled “Orange.”

"outcome": "Orange",
"evidence": [
  {
    "extract": "This exotic automobile is of the color tangerine.",
    "relevance": "Tangerine is a shade of orange..."
  }
]

In the same request, the system matched the word “automobile” to an ItemType:

"outcome": "car",
"evidence": [
  {
    "extract": "This exotic automobile...",
    "relevance": "The term 'automobile' directly indicates the item is a car."
  }
]

This behavior mirrors how a domain expert would interpret the text — with generalization, synonym understanding, and precision.

🎯 Example: Extraction with Dynamic Enum Matching

This new capability also extends to the Extraction API.

Suppose you’re extracting product information from descriptions, and one of the fields is a color. Rather than listing every possible color in your schema, you can point the extraction definition to a shared color vocabulary using enumSourceConfig.

Here’s what that looks like in your definition:

"color": {
  "type": "string",
  "description": "The color of the product.",
  "enumSourceConfig": {
    "sourceEntityType": "descriptor",
    "filter": {
      "type-name": "item.attribute.color.name",
      "similarity-threshold": 0.1,
      "result-count": 50,
      "branch-id": "00000000-0000-0000-0000-000000000000"
    }
  }
}

With this configuration, the Extraction API will:

• Fetch up to 50 possible color descriptors
• Use semantic similarity to choose the best match from the list
• Ground the output in your organization’s vocabulary

📝 Input Text:

The Mustang Mach-E is of a dark purple raisin like color.

🧠 Extracted Output:

{
  "product": {
    "name": "Mustang Mach-E",
    "color": "Purple"
  }
}

Here, the model understands that “dark purple raisin like color” refers to “Purple” and maps it to a standardized descriptor—without you needing to anticipate every variant or synonym.

🔍 Why This Matters

Handling large lists of possible outcomes—whether product categories, issue types, or other controlled vocabularies—is a common pain point in extraction and assertion workflows. Without an efficient, scalable solution, you risk:

• Slower processing times and higher costs from bloated prompts
• Inconsistent or inaccurate matches due to overwhelming the model with irrelevant options
• Complex maintenance from hardcoding enums across multiple schemas and systems

By semantically narrowing options before passing them to the model, you ensure faster, more cost-effective inference without compromising data integrity. This means your systems can scale gracefully, maintain consistent vocabularies, and deliver precise, reliable results—whether you’re working with tens or tens of thousands of possible outcomes.

In short, this approach empowers your team to build smarter, leaner data pipelines that keep pace with growing business demands.

Whether your list of possible values is 10 or 10,000, the model can still pick the right one—backed by reasoning and relevance.

🧪 Try It Out

These capabilities make the Assertion and Extraction APIs smarter, more precise, and more aligned with your goals. Whether you’re building claim workflows, reconciliation pipelines, or document understanding tools — this unlocks new levels of flexibility.

Go check out the Content API on RapidAPI and give the extraction capability a try!