A policy assistant can have the right answer in its documents and still fail to find it. If a question about physical therapy retrieves the wrong passage, a fluent language model cannot ground its answer. Embedding quality is therefore a retrieval reliability issue, not just a model-selection detail. section 4.0
An embedding is a list of numbers representing the meaning of a sentence, paragraph, or document—for example, [0.12, -0.87, 0.56, ...]. It places text at a point in a high-dimensional vector space. A useful embedding model places similar meanings near one another even when their wording differs: a question about therapy reimbursement can land near a passage about submitting a mental-health claim. Cosine similarity compares vector direction; dot product also reflects magnitude. section 4.1
In a retrieval-augmented generation (RAG) pipeline, embeddings connect document preparation to search:
- Load documents, split them into chunks, embed each chunk, and store its vector in a searchable repository. Chunking makes the indexed passages more precise. section 3.4
- Embed the user’s question with the same model, then search for nearby document vectors. Pass relevant passages to the language model as context; a poor match can leave it without the answer. section 4.0 section 4.2
- Keep identifying metadata alongside each vector. Policy ID, effective date, and status can help filter results to current, relevant policies. section 4.5.4
Embedding health-care policies
Split policy documents into chunks, encode their text with `SentenceTransformer('pritamdeka/S-PubMedBert-MS-MARCO')`, and create a Pinecone index whose dimension matches the resulting vectors. Configure cosine similarity, upsert vectors with their chunk text and policy metadata, then encode each question before querying. A medical-literature-trained model is chosen for health-care terminology; the model choice affects which passages are retrieved. section 4.5.4
def search_policies(query, filters=None, top_k=3):
"""
Search policy documents with semantic search and optional filters
Args:
query: User question or query string
filters: Dictionary of metadata filters to apply
top_k: Number of results to return
Returns:
List of relevant policy chunks with metadata
"""
query_embedding = model.encode([query])[0].tolist() #1
filter_dict = None #2
if filters: #2
filter_dict = {} #2
for key, value in filters.items(): #2
filter_dict[key] = value #2
query_results = index.query( #3
vector=query_embedding, #3
filter=filter_dict, #3
top_k=top_k, #3
include_metadata=True #3
)
results = [] #4
for match in query_results['matches']: #4
results.append({ #4
"score": match['score'],
"content": match['metadata']['content'],
"section_title": match['metadata']['section_title'],
"policy_id": match['metadata']['policy_id'],
"department": match['metadata']['department'],
"effective_date": match['metadata']['effective_date']
})
return results
query = "What's covered for physical therapy after knee surgery?" #5
filters = {"status": "Active", "department": "Benefits"} #5
results = search_policies(query, filters) #5
for i, result in enumerate(results): #6
print(f"\nResult {i+1} (Score: {result['score']:.4f})")
print(f"Policy: {result['policy_id']} ({result['department']})")
print(f"Section: {result['section_title']}")
print(f"Content: {result['content'][:200]}...")
The search function shows the operational path from question to query embedding, optional metadata filters, and top-k vector matches. section 4.5.4
Semantic proximity is useful, but it does not guarantee the right context. Generic pretrained embeddings can miss domain vocabulary; question–document pairs or synthetic questions can support in-domain fine-tuning. New document types may require retraining. Check retrieval quality rather than treating a successfully generated vector—or a fluent final answer—as proof that the right evidence was found. section 3.7.1 section 4.0
