Documents change daily, and the vector index must stay current with little custom work. What fits?
Why B is the answer
An AI Search index built from a Delta table
An index built from a source table can stay current as that table changes.
In detail
- An index built from a source table can stay current as that table changes.
- That removes the custom rebuild work.
- Databricks now also calls Vector Search by the name AI Search.
Use case
An illustrative scenario, not a real incident.
A policy team edits documents daily. The team keeps text in a Delta table, and an index built from that table follows the changes with no rebuild script to maintain.
See it in different ways
flowchart LR A["Source documents"] --> B["Extract text"] B --> C["Filter extraneous content"] C --> D["Chunk"] D --> E["Delta table in Unity Catalog"] E --> F["Vector Search index"]
stateDiagram-v2 [*] --> Raw Raw --> Text: parse or OCR Text --> Clean: remove extraneous content Clean --> Chunked: split Chunked --> Governed: Delta table in Unity Catalog Governed --> Indexed: Vector Search Indexed --> [*]
flowchart LR S0["Documents change"] --> S1["Delta table updated"] --> S2["Index syncs"] --> S3["Search finds new text"]
Key point: Build the index from a source table, so it follows the data.
Why the other options are wrong
- A. A scheduled notebook that rebuilds the whole index
- A full rebuild each time is the custom work you are trying to avoid.
- C. Embeddings stored in a CSV and reloaded nightly
- A CSV sits outside governance, and a nightly reload lags behind.
- D. A form that asks users to reupload changed files
- Asking users to reupload files depends on them remembering.