After hearing about semantic search, an engineer may assume every specification assistant needs a vector database. Start with the workload instead. A handful of short, approved documents may be easier to inspect using ordinary text search. Embeddings become useful when the collection and question vocabulary justify similarity retrieval. A vector database is one possible storage and search component, not a prerequisite for learning RAG or for answering a small set of specification questions.
An embedding model turns input text into a fixed-format numeric representation. A retriever compares the query representation with stored passage representations and selects candidates. You do not need to derive the vector arithmetic to use this idea responsibly. You do need to know which model and configuration created the representations, whether the model expects different handling for queries and documents, and whether all stored vectors belong to the compatible representation space. A list of invented numbers would demonstrate storage mechanics, not semantic quality, so this lesson uses no fake embedding model.
Stored item | Example or purpose |
|---|---|
chunk_id | reset-v2 points to a specific passage, not an answer. |
Text and locator | Original wording, DemoFIFO 2.0 section 3.1, synthetic source locator. |
Metadata | Project, revision, approval, access scope, extraction snapshot. |
Embedding provenance | Actual model identifier and processing settings, if embeddings are used. |
Search representation | Optional embedding stored with the same chunk identity. |
Imagine the owner corrects the reset requirement in a new revision 2.1. Add the approved 2.1 passage with its own identity and retrieval metadata. If semantic search is used, create its representation with the selected compatible model. Preserve 2.0 for branches that still use it, but ensure revision filtering happens before accepting candidates. If access to the document is revoked, remove or disable its searchable text, vectors, cached excerpts, and derived answers under the owner's retention policy.
For storage, an in-process list can be sufficient for a tiny experiment. A larger deployment may need a searchable index or dedicated service for filtering, concurrent readers, updates, and access control. Evaluate those capabilities against the actual collection and users. Do not let a storage choice dictate the evidence policy. A system that retrieves quickly but cannot enforce revision and access filters is unsuitable for controlled engineering documents.
No. Equal length does not imply compatible representations. Keep separate indexes or re-embed the approved collection with one compatible configuration, then review retrieval behavior. Preserve a manifest connecting text, chunk IDs, model configuration, and collection snapshot.
A useful design review asks where original text lives, how a citation resolves, how revision filters are applied, and how deletion propagates. Ask who is allowed to compute embeddings and where that computation happens. An embedding derived from proprietary text is still a data-handling concern; sending it or its source to a service requires approval for that destination. Prefer approved read-only access for users of the resulting assistant and keep ingestion privileges separate.
Embeddings can encode similarity without preserving an exact numeral, negation, or signal name well enough for a requirement decision. Always inspect retrieved text. Vector search does not replace structured SQL for exact counts or source review for normative claims. Reference: Sentence Transformers semantic-search documentation, consulted 2026-10-18. Model behavior and service features depend on the actual selected version; this lesson makes no product-capability or performance claim.