Implement Knowledge Mining and Information Extraction Solutions
The pipeline
Data source → indexer → skillset → index (and optionally a knowledge store). An indexer crawls a supported source (Blob Storage, Azure SQL, Cosmos DB, ADLS), applies a skillset of enrichment skills (OCR, key phrases, entities, custom models, embeddings), and writes fields into the index. Change detection keeps subsequent runs incremental; the enrichment cache preserves skill outputs so re-indexing after a schema or skill change is cheaper.
Index schema
Every index needs one key field (Edm.String, one per document). Field attributes are decisive: searchable (full-text analysed), filterable (OData $filter), sortable, facetable, retrievable (returned in results), plus analyzer and synonym-map choices. An attribute can be enabled later, but changing a field's type or key status requires rebuilding the index.
Querying
Support keyword search, filters/facets from filterable fields, scoring profiles to boost freshness or fields, and vector search (embeddings field with an HNSW or exhaustive KNN algorithm) combined with text into hybrid queries. The semantic ranker re-ranks the top results using language understanding; it needs semantic configuration and does not replace relevance - it refines it.
Information extraction extras
Document Intelligence prebuilt or custom models extract fields from forms and invoices; a custom extraction model is trained on labelled samples and evaluated by accuracy per field.
Traps and rule of thumb
Candidates forget that a field must be filterable to be used in $filter, that retrievable: false still allows filtering but hides the value, and that a skillset needs an indexer (it is not called directly).
Rule of thumb: for every field ask - searched, filtered, sorted, faceted or returned? Set those attributes at design time.