A question may use different words from the document that answers it. Vectorization makes meaning-based retrieval possible: an embedding model converts text into numerical vectors, or embeddings, so a vector store can compare a question with stored content by similarity rather than exact wording. section 6.1.3
In a retrieval-augmented generation (RAG) application, vectorization happens on both sides of the search:
- Indexing: load documents, split them into manageable chunks, convert each chunk into an embedding, and store the chunks alongside their vectors. Small chunks help searches find focused passages; embedding models also have finite input sizes. section 6.1.3
- Answering: embed the user's question, search for similar stored vectors, and put the retrieved text—not just its vector—into the prompt for the language model. section 7.1.2
Search without matching words
A search for “feline animals” can retrieve chunks about cats, lions, and tigers even when those chunks never say “feline.” In a Chroma example, a question about Paestum's Doric temples retrieves the chunk containing the answer, its source metadata, and a query-to-chunk distance. section 6.1.3 section 6.2.5
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500, chunk_overlap=0)
embeddings_model = OpenAIEmbeddings(
openai_api_key=OPENAI_API_KEY)
vector_db = Chroma("tourist_info", embeddings_model)
This LangChain setup pairs a text splitter with OpenAIEmbeddings and a Chroma vector store; documents are then split and added to the store. section 7.2.1
Keep ingestion and retrieval embeddings compatible: their dimensions must match, and changing models requires re-embedding the stored content. Vectorization does not rescue poor chunks; mid-sentence splits or missing context can still produce weak answers. Some vector stores generate embeddings when text is added, so a separate precomputation step is not always needed. section 6.4 section 7.1.1
