6.2.1. Using Analyzers and the Foundry Playground
💡 First Principle: An analyzer is the configured extractor — it defines which fields to pull from a given kind of content. Prebuilt analyzers handle common scenarios out of the box; custom analyzers let you define fields for your own content. The Foundry portal's analyzers playground lets you test either without writing code.
The workflow mirrors the model and agent flows: explore in the playground (does this analyzer pull the right fields from my sample?), then move to code once it works. Prebuilt analyzers get you started immediately for things like common document types; custom analyzers are the path when your content or required fields are specific to your business.
⚠️ Exam Trap: Prefer a prebuilt analyzer when one fits your content type — building a custom analyzer when a prebuilt one would do is wasted effort. Reach for custom only when your fields or document types aren't covered by a prebuilt option. (Echoes the Phase 3 "don't over-build" judgment.)
Reflection Question: When does it make sense to build a custom analyzer instead of using a prebuilt one? What question about your content settles it?
