A transit authority wants one retrieval corpus spanning an internal wiki and PDF SOPs, with filters for transit mode and route. What vector-store design element is most critical?
Select an answer to reveal the explanation.
Short Explanation
Wiki pages and SOP PDFs can share one bookshelf if every binder gets labeled. Tag chunks with mode and route metadata so retrieval pulls bus SOP #12, not a random rail wiki note.
Full Explanation
A transit authority that needs one corpus across an internal wiki and PDF SOPs, filterable by mode and route, must unify ingestion while preserving filter attributes. The critical design element is a shared vector index (or logically unified retrieval surface) where each chunk carries mode and route metadata. That lets one assistant ground answers in both wiki and SOP text while restricting results to bus vs rail or a specific route when residents or operators ask.
Discarding all SOP metadata so every chunk is equal priority fails because filters become impossible and cross-mode contamination rises. Creating separate foundation models per PDF page fails conceptually—that is not a retrieval-corpus design and explodes cost and governance. Limiting ingestion to wiki titles and excluding SOP body text fails because titles alone cannot answer procedural questions the SOPs contain.
Exam caveat: Unified multimodal-source RAG still depends on metadata for precise civic filters; unification without attributes is incomplete.
Operational check: assert mode/route tags on wiki and SOP chunks at ingest, run filtered retrieval tests (e.g., bus route 12 SOP vs rail wiki), alert on untagged chunks, and periodically reconcile route codes with the transit master schedule.