Recently, I worked on a project where I used AI and RAG to improve how clinical guideline information can be retrieved and used in a healthcare workflow.
The main idea was simple:
Instead of allowing the AI to answer based only on general model knowledge, I wanted the system to first search through trusted clinical guideline content and use that retrieved context to support the response.
This is where RAG comes in.
RAG means Retrieval-Augmented Generation. In simple terms, it allows an AI system to retrieve relevant information from a knowledge base before generating an answer.
The problem
In healthcare, AI responses need to be more than just fluent.
They need to be:
- Relevant
- Grounded
- Structured
- Safe
- Based on trusted information
A doctor may ask about symptoms, possible diagnosis, investigations, treatment options, or drug recommendations. The system should not just generate a generic answer. It should first look through available clinical guideline data and return context that can support a better response.
What I built
I worked on a RAG pipeline that does the following:
- Reads clinical guideline data
- Breaks the content into useful chunks
- Generates embeddings for each chunk
- Stores the embeddings in PostgreSQL using pgvector
- Accepts a doctor’s prompt
- Generates an embedding for the prompt
- Searches for the most relevant guideline chunks
- Retrieves related treatment sections
- Sends the retrieved context to the AI model for a better response
The backend was built with .NET, PostgreSQL, and pgvector.
Why pgvector?
I used pgvector because it allows PostgreSQL to store and search vector embeddings.
This means I can keep the data in a familiar SQL database while still supporting semantic search.
Instead of searching only by exact keywords, the system can search by meaning.
For example, if a doctor describes a condition or symptom, the system can retrieve guideline content that is semantically related to the prompt.
One important improvement
One thing I worked on was making sure the system did not only return the closest vector matches.
I also added logic to retrieve treatment-related sections for the top matching condition.
This helps the AI response include useful information such as:
- Treatment goals
- Non-drug treatment
- Drug treatment
- Cautions
- Supportive measures
- Definitive treatment
That part was important because healthcare responses should not stop at possible diagnosis. Doctors also need practical next steps.
What I learned
One major lesson from this project is that RAG is not just about adding AI to an application.
The quality of the response depends heavily on:
- How the data is structured
- How the data is chunked
- How retrieval is designed
- How relevant context is selected
- How the prompt guides the final answer
Good RAG is not magic. It is engineering.
Why this matters
AI becomes more useful when it is connected to the right data.
For healthcare, this can help support doctors with faster access to guideline-based information, while still keeping the human expert in control.
This project gave me a deeper appreciation for how AI can be used in real products, not just demos.
I am still improving the retrieval flow, query performance, and response structure, but this was a strong step forward in building practical AI systems with .NET.
Tech used
- .NET
- PostgreSQL
- pgvector
- OpenAI embeddings
- Vector search
- RAG
- Clinical guideline retrieval
Still learning. Still building.
Top comments (0)