How to Get Better Technical Answers from Claude Using Your Own Documentation

If you're enjoying this article and have a Medium subscription, I'd greatly appreciate if you'd open and read it there — your support helps me continue creating quality content like this!

Update: New title (previously it was "RAG in Action: Advanced Retrieval Techniques with Claude Desktop").

In the first part of this series, we built the foundation of our RAG system by setting up Qdrant, processing our AI-friendly Angular documentation, and configuring the MCP server to connect with Claude Desktop. This built upon our earlier exploration of AI-friendly documentation, where we saw how properly structured technical documentation significantly improves LLM responses.

Now that our infrastructure is in place, it's time to put it to work and explore increasingly sophisticated techniques for retrieving and leveraging documentation with Claude. The true power of RAG isn't just in having access to documentation—it's in how effectively you retrieve and use that information.

In this article, we'll progress from basic queries to advanced techniques that improve the quality and relevance of Claude's responses. We'll explore:

1. Basic RAG Queries for straightforward questions
2. 2-Step Method with Improved Response Synthesizer for better focus and precision
3. 3-Step Method with Multi-Query Retrieval for comprehensive coverage
4. Best practices and optimization strategies based on real-world experience

Whether you're using our Angular documentation or applying these techniques to your own knowledge base, these methods will transform how you interact with technical documentation through Claude.

Basic RAG Queries: Your First Retrieval Example

Let's see our RAG system in action with a simple example that builds on our standalone components question from the previous article. We'll ask: "Are standalone components default in Angular?"

In Claude Desktop, we'll use the following prompt with Claude 3.5 Haiku model since its knowledge cutoff date is before the release of Angular 19:

🧑: Use qdrant_retrieve on angular-19.2.3 collection, 
retrieve documents matching for the question: 
"Are standalone components default in Angular?".
Retrieve 50 documents.

When you send this message, several things happen behind the scenes:

1. Claude recognizes the request to use the qdrant_retrieve provided by the Qdrant Retrieve MCP Server
2. It sends your question to the MCP server
3. The server converts your question to a vector embedding
4. Qdrant searches for the 50 most similar document chunks
5. The retrieved chunks are sent back to Claude
6. Claude incorporates this information into its response

Understanding the Retrieval Request and Response

The MCP server receives a request that looks something like this:

{
  "topK": 50,
  "query": ["Are standalone components default in Angular?"],
  "collectionNames": ["angular-19.2.3"]
}

Qdrant then performs a vector similarity search and returns the most relevant document chunks. These typically include sections from the Angular documentation discussing standalone components, their configuration options, and default settings.

Claude receives these chunks and now has the specific information needed to provide an accurate, version-specific answer.

Analyzing Document Relevance Scores

Each retrieved document comes with a relevance score indicating how closely it matches your query. These scores range from 0 to 1, with higher values indicating greater relevance.

For our question about standalone components, we might see results like:

1. Documentation section on component creation options (score: 0.92)
2. Guide section about standalone components (score: 0.89)
3. API reference for ComponentOptions interface (score: 0.87)
4. Migration guide mentioning standalone defaults in Angular 19 (score: 0.86)
5. ... (and so on)

The documents clearly mention that in Angular versions before 19.0.0, the standalone option defaulted to false, but starting with Angular 19, standalone components are the default.

How Claude Uses the Retrieved Context

With this information available, Claude constructs an accurate response:

🤖: Yes, standalone components are now the default in Angular.
This changed in Angular version 19.0.0, where the standalone
option began defaulting to true. In previous versions (before 19.0.0),
the standalone option defaulted to false, which meant components
needed to be part of an NgModule by default.

This change reflects Angular's gradual move toward a modular
architecture that doesn't require NgModules for basic functionality.
Standalone components can be directly added to the imports array of
other components without needing a module.

Notice how Claude's response incorporates specific details from the retrieved documentation, including the version number where the change occurred. This is the power of RAG in action—Claude is able to provide version-specific information that might not have been in its original training data.

2-Step Method with Improved Response Synthesizer

While basic retrieval works well for straightforward questions, we can implement a more sophisticated approach for complex queries. This 2-step method mimics how a human researcher might work: first gathering information, then focusing on what's most relevant.

Why the 2-Step Method Works Better

The 2-Step Method breaks the retrieval and response process into two key stages:

1. Initial retrieval with filtering: Gather relevant documents and immediately identify the most valuable ones
2. Focused response generation: Create a precise answer based only on the most relevant information

This focused approach often improves response quality through enhanced synthesis capability. By concentrating on the most pertinent information, the LLM can create more precise, authoritative answers.

Implementing the 2-Step Method

Let's apply this technique to our standalone components question:

Step 1: Initial retrieval with filtering

🧑: Use qdrant_retrieve on angular-19.2.3 collection, retrieve documents
matching for the question: "Are standalone components default in Angular?".
Retrieve 50 documents, then show me the 3 most relevant ones
for answering this question.

This first prompt retrieves documentation and immediately identifies the most valuable chunks. Unlike the basic method, this approach intelligently filters for relevance before the final response generation.

From the 50 retrieved documents, Claude would identify three key ones:

1. A section from the component creation guide that explicitly states: "Starting from Angular 19.0.0, the standalone option defaults to true."

2. API documentation for the Component decorator showing: "standalone?: boolean - If true, this Component is not part of any NgModule. Default is true starting from v19, default was false before v19."

3. A migration guide section explaining the change: "Angular 19 changes the default for components, directives, and pipes to be standalone by default. This makes the framework more approachable for new developers."

Step 2: Generating a precise, document-backed response

🧑: Based on these 3 most relevant documents, answer the question:
"Are standalone components default in Angular?"

With the filtered context, Claude produces a concise, accurate response:

🤖: Yes, standalone components are the default in Angular, but this
is a relatively recent change. According to the Angular documentation:

1. Starting from Angular 19.0.0, the standalone option defaults to true
2. Before Angular 19.0.0, the standalone option defaulted to false
3. This change was made to make the framework more approachable for new developers

This means that if you're using Angular 19 or newer, any new components
you create will be standalone by default unless you explicitly set
`standalone: false` in the component decorator.

Notice how this 2-step method yields a precise answer with specific version information and rationale for the change. The improved response synthesizer creates well-structured content directly tied to the most relevant documentation sources.

3-Step Method with Multi-Query Retrieval

Building on our 2-Step Method, the 3-Step Method with Multi-Query Retrieval takes result quality even further. By introducing query variation as a preliminary step, this technique addresses a fundamental limitation in RAG systems: the phrasing of your original query might not perfectly match how information is expressed in the documentation.

Why Query Generation Improves Results

A single query, no matter how well-formulated, can miss relevant documentation due to vocabulary mismatches or missing context. For example, when asking about "standalone components in Angular," relevant documentation might use phrases like:

• "Components without NgModules"
• "Self-contained components"
• "Components with standalone: true"
• "Module-less components"

By generating multiple alternative queries, we cast a wider net and increase our chances of finding all relevant information, even when it uses different terminology or approaches the concept from different angles.

Implementing the 3-Step Method

Let's apply this comprehensive technique to our standalone components question:

Step 1: Generate multiple query variations

🧑: Generate 9 RAG queries based on the question "Are standalone components
default in Angular?". Then use qdrant_retrieve on angular-19.2.3
collection for retrieving 50 documents.
Do not reply, just retrieve the documents.

In this first step, Claude creates multiple versions of the query, each phrased differently to maximize retrieval coverage. For example:

1. "Are standalone components the default option in Angular 19?"
2. "Did Angular change the default value of standalone in component configuration?"
3. "What is the default value of the standalone property for Angular components?"

Step 2: Retrieve and filter results across all queries

🧑: Show the 3 documents that help most for answering
the original question better.

This step consolidates the results from all queries, identifying the most relevant documents across the entire retrieval set.

Step 3: Enhanced response synthesis

🧑: Based on these 9 documents, answer the original question:
"Are standalone components default in Angular?"

With input from multiple angles combined with the improved response synthesizer, Claude produces a comprehensive answer that incorporates insights from diverse query perspectives, creating the most authoritative and complete response possible.

🤖: Yes, standalone components are the default in Angular.
Based on the documentation:

Components must be explicitly marked as standalone: false
to be declared in an NgModule, indicating that the default state
is standalone.

The Angular team officially recommends using standalone components
instead of NgModules for all new code.

When migrating existing code, the process involves removing
standalone: false flags and adding imports directly to components,
showing that standalone is now the standard approach.

Angular provides a strictStandalone compiler option that,
when enabled, reports errors if components aren't standalone,
reinforcing this as the preferred pattern.

The framework offers dedicated bootstrapping methods for
standalone components (bootstrapApplication), which is
recommended over the NgModule-based approach.

In summary, while Angular maintains backward compatibility
with NgModule-based applications, standalone components are
now the default and recommended approach for building Angular
applications.

Summary and Future Directions

Throughout this series on AI-friendly documentation and RAG systems, we've discovered that:

1. Documentation structure matters: As we saw in the first article, clear headers and well-organized content dramatically improve retrieval quality

2. Vector embeddings preserve meaning: Our LlamaIndex-powered pipeline converts documentation into semantic chunks that maintain their contextual relationships

3. Retrieval strategy is as important as infrastructure: The techniques you use to query your documentation can be even more important than the underlying technical setup

4. Multiple approaches yield better results: Combining different retrieval strategies provides more comprehensive coverage of complex topics

Future Directions

This is just the beginning of what's possible with RAG systems for documentation. Here are some exciting directions to explore:

• Multi-collection retrieval: Search across multiple documentation sources simultaneously (e.g., Angular, TypeScript, RxJS)
• Adaptive retrieval strategies: Automatically select the optimal retrieval technique based on question type. For example, we should use different approaches when searching inline comments in source code versus formal Angular documentation
• Automated evaluation: Measure the quality of responses against ground truth answers
• Token-based retrieval limits: Rather than retrieving a fixed number of documents, optimize retrieval by setting token limits. This balances relevance with cost efficiency, as token usage directly impacts API costs while ensuring you get the maximum relevant information.
• Hierarchical document retrieval: Build retrieval systems that understand document structure and can pull in related sections from the same document. This maintains the contextual continuity between retrieved chunks while still focusing on the most relevant information.

Beyond Documentation

While we've focused on Angular documentation in this series, the techniques we've explored apply to any domain with structured knowledge. Consider applying these approaches to:

• Internal company documentation and knowledge bases
• Product manuals and support documentation
• Legal documents and regulatory frameworks

By understanding and implementing these RAG techniques, you're not just improving how you interact with Angular documentation—you're developing skills that transform how you work with information across all domains.

About the Author

My name is Gergely Szerovay. I've worked as a data scientist and full-stack developer for many years, and I've been a frontend tech lead focusing on Angular development for the past three years. To closely follow the evolution of AI-assisted software development, I've decided to start building AI tools in public and publish my progress on AIBoosted.dev.

Follow me on Substack (Angular Addicts), Substack (AIBoosted.dev), Medium, Dev.to, X or LinkedIn to learn more about Angular and how to build AI apps with AI, TypeScript, React, and Angular!