The Developer's Guide to Context Window Optimisation

... Or Why Your RAG System Isn't Working and How to Fix It

You've built a RAG system that works great in demos but falls apart in production. Your users complain about inconsistent responses, your costs are spiralling, and you're constantly hitting token limits. Sound familiar?

A few months ago, an ex-colleague from a financial services team chatted with me about this problem. It chimed with my own experiences, so I did some digging into the reasons behind this which you can see in the references, meanwhile, their document Q&A system would perfectly answer questions about quarterly reports during testing, but when deployed, it would randomly miss obvious information or hallucinate details that weren't in the source documents. After digging into their implementation, the issue wasn't their embedding model, their vector database, or even their retrieval strategy. It was something far more fundamental, they were essentially playing Russian roulette with their most important information by randomly ordering retrieved documents in their context window.

The problem likely isn't your model choice or your retrieval strategy, it's how you're organising context in your prompts. After analysing production systems, academic research, and enterprise implementations, a clear pattern emerges: context organisation has a bigger impact on performance than most developers realise. Small changes in how you arrange information can deliver accuracy improvements while reducing costs.

The Needle in a Haystack Problem Is Killing Your Accuracy

Here's something that should fundamentally change how you think about context. LLMs exhibit a U-shaped performance pattern where information in the middle of long contexts gets effectively ignored. This isn't theoretical, it's been tested across multiple model architectures and consistently shows accuracy drops of 30-50% when relevant information is buried in the middle positions of your context window. Think about how this plays out in a typical RAG system. You retrieve 10 relevant documents, concatenate them in the order your vector database returns them, and pass the whole thing to your LLM. If the most relevant information ends up in positions 4-7 of your context, your model might perform worse than if you hadn't retrieved any documents at all. This isn't a bug, it's how attention mechanisms work. The transformer architecture that powers modern LLMs was designed with inductive biases that favour the beginning and end of sequences. When you're dealing with long contexts, the middle 30-70% of your information gets progressively less attention weight, creating a performance valley that can devastate your system's reliability.

The financial services team I mentioned earlier was experiencing exactly the same thing. Their system would correctly answer questions when the relevant quarterly data appeared in the first or last retrieved document, but would hallucinate or claim ignorance when the same information was buried in the middle of their 8-document context window. They had optimised everything except the one thing that mattered most - information positioning.

The fix is surprisingly simple, reverse relevance ordering. Place your highest-relevance content at the beginning and end, with lower-relevance material in the middle. This single change rescued their system from performing worse than baseline and improved their accuracy by 40% according to their testing.

# Don't do this - random ordering based on retrieval

context = "\n".join([doc.content for doc in retrieved_docs])

# Do this instead - strategic positioning

sorted_docs = sort_by_relevance(retrieved_docs)

context = (

    sorted_docs[0].content +  # Highest relevance first

    "\n".join([doc.content for doc in sorted_docs[2:-1]]) +  # Middle content

    sorted_docs[1].content  # Second highest at the end

)

The pattern holds across different model sizes, architectures, and domains. Whether you're working with Claude, GPT-4x, or open-source models, the U-shaped attention pattern remains consistent. It's not going away with bigger context windows either, if anything, it becomes more pronounced as contexts get longer.

Your Chunking Strategy Is Probably Wrong

Most developers default to fixed-size chunking because it's the first example they see in tutorials. You pick 512 or 1024 tokens, split your documents, and call it done. But this approach treats all content as equivalent, breaking apart sentences, splitting tables in half, and destroying the semantic relationships that make information useful.

I've looked at quite a few RAG systems, and the pattern is consistent, teams that stick with naive fixed-size chunking hit accuracy ceilings they can't break through. Meanwhile, semantic chunking outperforms fixed-size approaches by a claimed 15-25% in retrieval accuracy, with the gap widening for complex queries that require understanding relationships between concepts. The key insight is that documents have a natural structure. A research paper typically consists of sections, subsections, tables, and figures. A technical manual has procedures, prerequisites, and troubleshooting guides. When you chunk at arbitrary token boundaries, you're throwing away this structure and forcing your retrieval system to work harder to understand what information belongs together.

The optimal configuration for most applications uses 1000-1500 token chunks with 200-300 token overlap (20%), scaling up to 2000-4000 tokens for complex reasoning tasks. But more importantly, preserve document hierarchy. When you chunk a technical document, maintain the relationship between headers, sections, and subsections. This metadata becomes crucial for retrieval quality, helping users understand where information originates.

# Semantic chunking with hierarchy preservation

def create_hierarchical_chunks(document):

    chunks = []

    for section in document.sections:

        for subsection in section.subsections:

            chunk = {

                'content': subsection.content,

                'metadata': {

                    'document': document.title,

                    'section': section.title,

                    'subsection': subsection.title,

                    'hierarchy_path': f"{document.title} > {section.title} > {subsection.title}",

                    'section_type': subsection.type,

                    'word_count': len(subsection.content.split()),

                    'contains_tables': bool(subsection.tables),

                    'contains_code': bool(subsection.code_blocks)

                }

            }

            chunks.append(chunk)

    return chunks

One enterprise team I spoke to was building a customer support system for a complex SaaS product. Their fixed-chunking approach was randomly splitting troubleshooting procedures across multiple chunks, making it impossible for the system to provide complete answers. After switching to semantic chunking, which preserved procedure boundaries, their resolution rate improved by 35% and customer satisfaction scores increased significantly.

The metadata you preserve during chunking becomes invaluable later. When users ask questions, you can use chunk metadata to provide better context about where information comes from, route queries to the most appropriate sections, and even identify when you might need to retrieve additional related chunks to provide complete answers.

Anthropic's Contextual Retrieval Changes Everything

While most RAG implementations focus on better embeddings or smarter retrieval algorithms, Anthropic took a different approach that addresses a fundamental problem: chunks lose context when stored in isolation. A paragraph about "quarterly revenue growth" makes perfect sense in the context of a Q3 earnings report, but stored alone in a vector database, it lacks the context needed for accurate retrieval and generation.

Their contextual retrieval approach solves this by prepending each chunk with LLM-generated context that explains what the chunk is about and where it fits in the larger document. This simple technique apparently reduces retrieval failures by 49% and achieves 67% improvement over naive RAG when combined with reranking.

The brilliance is in its simplicity. Instead of trying to encode more information into embeddings or building complex knowledge graphs, they use the LLM itself to create rich context for each chunk. This context acts as a bridge between the specific details in the chunk and the broader document structure.

def add_contextual_prefix(chunk, document):

    prompt = f"""

    Document: {document.title}

    Document type: {document.type}

    Publication date: {document.date}

    Full document context: {document.summary}    

    Chunk: {chunk.content}

  Provide a brief, contextual introduction (2-3 sentences) for this chunk that explains:

    1. What specific topic or concept this chunk covers

    2. How it relates to the overall document

    3. Any important context needed to understand it standalone

    Keep it concise but informative.

    """

    context_prefix = llm.generate(prompt)

    return f"{context_prefix}\n\n{chunk.content}"

I've implemented this approach across several production systems, and the results are consistently impressive. A legal tech company saw their contract analysis accuracy improve by 45% after adding contextual prefixes that explained which section of the contract each chunk came from and what legal concepts it addressed. The system went from giving vague answers about "liability provisions" to providing specific guidance about indemnification clauses in software licensing agreements.

The computational overhead is minimal compared to the benefits. You generate these contextual prefixes once during document ingestion, not at query time. The extra tokens in your vector database are more than offset by the improved retrieval accuracy, which means you need fewer chunks to answer questions correctly.

Context Window Budgeting The 60-70% Rule

Your context window isn't unlimited, even with models offering millions of tokens. More importantly, there's a sweet spot for context utilisation that balances performance with cost-effectiveness. Optimal utilisation targets 60-70% of available capacity—beyond this threshold, you hit diminishing returns and exponentially increasing costs.

This isn't just about avoiding token limits. As context windows get fuller, several things happen: attention becomes more diffuse, latency increases significantly, and the model becomes more prone to generating responses that don't properly synthesise all the available information. It's like trying to have a conversation in a crowded room—more voices don't necessarily mean better communication.

Here's the token budget allocation that works best in production systems I've analysed:

• System instructions: 5-10% (core behaviour and constraints)

• Examples and demonstrations: 15-25% (few-shot examples and formatting)

• Retrieved context: 40-50% (your RAG documents and relevant information)

• User input and conversation: 10-15% (current query and recent history)

• Buffer for output: 5-10% (space for complex responses)

These percentages aren't arbitrary—they reflect how different types of information contribute to output quality. System instructions need to be concise but comprehensive. Examples should provide clear patterns without overwhelming the context. Retrieved content is your primary information source, but shouldn't crowd out everything else. Conversation history provides continuit,y but should be compressed or truncated as it ages.

def manage_context_budget(context_parts, max_tokens):

    budget = {

        'system': int(max_tokens * 0.1),

        'examples': int(max_tokens * 0.2),

        'retrieved': int(max_tokens * 0.45),

        'conversation': int(max_tokens * 0.15),

        'buffer': int(max_tokens * 0.1)

    }

    # Trim each section to budget, prioritising quality over quantity

    for part_name, content in context_parts.items():

        if part_name in budget:

            context_parts[part_name] = trim_to_budget(

                content, 

                budget[part_name],

                preserve_structure=True

            )

    # Verify total doesn't exceed limit

    total_tokens = sum(count_tokens(part) for part in context_parts.values())

    if total_tokens > max_tokens * 0.7:  # Our target utilization

        # Intelligent trimming to fit the budget

        context_parts = trim_to_fit(context_parts, max_tokens * 0.7)

    return context_parts

Monitor your token usage religiously. Context Window Overflow (CWO) is a common failure mode in which systems exceed their limits, resulting in silent truncation and garbled outputs. I've seen production systems that worked perfectly in testing fail catastrophically in production because they didn't account for variable input lengths and edge cases where retrieved context exceeded expectations.

One e-commerce company I worked with was building a product recommendation system. Their context window management was so poor that long product descriptions would get silently truncated, leading to recommendations based on incomplete information. Customers would see suggestions for "wireless headphones" when they were looking at "wireless headphone cases." Proper context budgeting fixed these edge cases and improved recommendation accuracy by 30%.

MCP and Tool Integration Structure Matters

If you're using Model Context Protocol (MCP) or similar tool integration systems, context organisation becomes even more critical. Each additional tool introduces its own schemas, examples, and potential outputs, creating a complex context management challenge that most developers underestimate.

The problem compounds quickly. With five active tools, you're not just managing five times the complexity—you're dealing with exponential growth in potential interactions, edge cases, and context fragmentation. Beyond five simultaneous tools, most systems begin to experience reliability issues that are difficult to diagnose and fix.

The hierarchy that works: System instructions establish overall behaviour, tool schemas are grouped by functional area, conversation history is compressed by relevance and recency, and tool results are positioned based on their importance to the current query. This isn't just about organisation—it's about making sure the model can effectively reason about which tools to use and how to combine their outputs.

def organize_mcp_context(tools, conversation, current_query):

    context_structure = {

        'system_instructions': build_system_prompt(),

        'tool_schemas': group_tools_by_function(tools),

        'relevant_examples': select_examples_for_query(current_query, tools),

        'conversation_summary': compress_conversation_history(conversation),

        'tool_results': prioritize_recent_results(conversation),

        'current_query': current_query

    }

    # Ensure tools are presented in logical order

    # Most general tools first, then specific ones

    context_structure['tool_schemas'] = sort_tools_by_generality(

        context_structure['tool_schemas']

    )

    return context_structure

MCP's standardised schemas help reduce context overhead, but you still need intelligent token management. Session-based context caching is crucial here, as it can reduce repeated context overhead by 40-60%. When the same tools are used across multiple queries in a session, you don't need to redefine their schemas every time.

I worked with a data analytics team that was building an AI assistant for business intelligence. They had integrated 12 different tools for database queries, visualisation, statistical analysis, and reporting. Initially, every query would include all 12 tool definitions, consuming 60% of their context window before any actual work began. By implementing smart tool selection based on query analysis and session caching, they reduced context overhead to 20% while actually improving tool selection accuracy.

The key insight is that not every tool needs to be available for every query. Implement intelligent tool selection that analyses the user's request and only loads relevant tools into context. This reduces noise and enables the model to focus on the most suitable capabilities for each task.

Compression Techniques, When and How

Context compression has evolved from a research curiosity to a production necessity, but it's not a magic solution. LLMLingua achieves up to 20x compression while maintaining performance for simple tasks; however, complex reasoning exhibits significant semantic loss. The art is knowing when compression helps and when it hurts.

The fundamental trade-off is between token efficiency and information preservation. Aggressive compression can turn detailed explanations into cryptic abbreviations that confuse rather than clarify. But intelligent compression of redundant or low-priority information can free up space for the content that truly matters.

The key is developing compression strategies that match your application's needs:

• Always compress: Historical conversation context older than 10 exchanges

• Selectively compress: Retrieved documents with low relevance scores

• Never compress: System instructions, critical examples, or current user inpu

def intelligent_compression(context_parts, query_complexity):

    compression_strategy = determine_strategy(query_complexity)

    if compression_strategy == 'aggressive':  # Simple queries

        # Heavy compression for background context

        context_parts['history'] = compress_conversation(

            context_parts['history'], 

            ratio=0.3,

            preserve_key_facts=True

        )

        context_parts['low_relevance_docs'] = compress_documents(

            context_parts['low_relevance_docs'],

            ratio=0.5,

            preserve_structure=True

        )

    elif compression_strategy == 'moderate':  # Medium complexity

        # Light compression to preserve reasoning paths

        context_parts['history'] = compress_conversation(

            context_parts['history'],

            ratio=0.7,

            preserve_recent=True

        )

    # Complex queries: minimal compression to preserve all reasoning paths

    return context_parts

def determine_strategy(query_complexity):

    if query_complexity < 0.3:

        return 'aggressive'

    elif query_complexity < 0.7:

        return 'moderate'

    else:

        return 'minimal'

One interesting pattern I've observed is that compression often improves performance on factual queries while hurting complex reasoning tasks. A customer service system I analysed actually performed better with compressed historical context because it reduced the chance of the model getting distracted by irrelevant past conversations. But for code generation tasks requiring a deep understanding of existing implementations, compression consistently degraded output quality.

Progressive context loading represents the next evolution in compression strategies. Instead of compressing everything upfront, these systems start with the most relevant context and expand as needed. This approach reduces average context size by 40-60% while maintaining accuracy for simple queries, with automatic escalation for complex reasoning tasks requiring broader context.

Common Anti-Patterns That Kill Performance

After auditing hundreds of RAG implementations, certain failure patterns emerge repeatedly. These anti-patterns are so common that fixing them often yields a greater impact than any algorithmic improvement.

Ignoring positional bias is the most critical mistake to avoid. Teams that randomly order retrieved documents, instead of using relevance-based positioning, suffer from a 30-50% accuracy degradation. It's the equivalent of burying your most important information where the model can't see it.

Over-stuffing the context is equally damaging. Using 90% or more of the available tokens leaves no room for complex outputs and often triggers context overflow errors in edge cases. I've seen systems that work perfectly in development fail in production because test queries were shorter than real user inputs.

Fixed chunking without context preservation destroys semantic relationships. Breaking apart procedures, splitting tables, or cutting off explanations mid-sentence forces the model to guess about missing information. One technical documentation system I reviewed was splitting installation procedures across multiple chunks, resulting in incomplete instructions that frustrated users and created unnecessary support tickets.

Missing metadata makes it impossible to provide proper attribution or understand the origin of the information. Users need to know whether an answer comes from official documentation, community discussions, or experimental features. Without metadata, even correct answers lack the necessary context for users to trust and act upon them.

No graceful degradation means systems fail hard when they encounter edge cases. A legal research system I worked with would crash entirely when processing unusually long contracts instead of intelligently trimming less relevant sections to fit within token limits.

Each of these anti-patterns creates cascading problems that are difficult to debug and fix after the fact. It's much better to design systems that avoid these pitfalls from the beginning.

Production Monitoring: What to Measure

You can't optimise what you don't measure, and context optimisation requires specific metrics that go beyond traditional accuracy measurements. The challenge is that context problems often manifest as subtle quality degradations rather than obvious failures.

Positional performance analysis tracks how accuracy varies based on the location of relevant information within your context. If performance drops significantly when key information is located in the middle of your context, you have a positioning problem that needs to be addressed.

Context utilisation rates help you understand how efficiently you're using available tokens across different request types. Are simple questions consuming as much context as complex ones? Are you consistently hitting budget limits or leaving capacity unused?

Information density measures how much relevant information you pack per token. Higher density usually means better performance and lower costs, but there's a balance—too much compression can hurt comprehension.

Retrieval-generation alignment ensures that retrieved context actually influences generated responses. I've seen systems that retrieve perfectly relevant documents but generate answers that ignore this information entirely due to poor context organisation.

def monitor_context_performance(queries, responses, contexts):

    metrics = {

        'positional_accuracy': analyze_position_bias(queries, responses, contexts),

        'utilization_rates': calculate_token_utilization(contexts),

        'information_density': measure_relevance_per_token(contexts),

        'retrieval_alignment': check_context_citation(responses, contexts)

    }

    # Alert on concerning patterns

    if metrics['positional_accuracy']['middle_position'] < 0.7:

        alert("Significant middle-position bias detected")

    if metrics['utilization_rates']['average'] > 0.85:

        alert("Context utilization too high - risk of overflow")

    return metrics

Set up A/B testing infrastructure to validate context organisation changes. Small improvements compound quickly at scale, but you need rigorous measurement to distinguish real improvements from noise. One financial services company I worked with improved their context organisation incrementally over six months, achieving a cumulative 60% improvement in answer accuracy through systematic testing and optimisation.

The key is establishing baselines before making changes and measuring the right things. Focus on user-facing metrics, such as task completion rates and satisfaction scores, rather than just technical metrics like token usage or retrieval accuracy.

The Economics of Context Optimisation

Context optimisation isn't just about accuracy—it's about cost. At enterprise scale, these optimisations can save hundreds of thousands of dollars annually while improving user experience. The economics are compelling because context optimisation reduces both computational costs and human review overhead.

Production systems report a 40-60% reduction in inference costs through proper context management. This happens through multiple mechanisms: more efficient token usage means fewer API calls, better context organisation reduces the need for follow-up questions, and improved accuracy means less human intervention to fix wrong answers.

One insurance company I worked with was spending $50,000 monthly on API costs for their claims processing system. After implementing systematic context optimisation—better chunking, intelligent compression, and strategic positioning—they reduced costs to $20,000 while improving claim processing accuracy by 35%. The ROI was immediate and sustainable.

The savings compound over time. Better context organisation leads to more reliable outputs, which reduces the need for human review and correction. This creates a virtuous cycle where improved technical performance drives operational efficiency.

The ROI is typically 3:1 to 10:1 on context optimisation initiatives, with additional productivity gains from more reliable system behaviour. Unlike model upgrades or infrastructure scaling, context optimisation is a one-time engineering investment that delivers ongoing benefits.

But the economic impact goes beyond direct cost savings. More reliable AI systems enable new use cases and higher user adoption. Teams often discover that fixing context issues unlocks capabilities they didn't know their system had.

Future-Proofing Your Context Strategy

Context windows are expanding rapidly, GPT-4.1 offers 1 million tokens, Anthropic's Claude handles 200k+ tokens effectively, Google’s Gemini has a window of 1m tokens since version 1.5 and experimental models push even higher. But bigger isn't always better. Most applications perform optimally with a focused, well-organised context rather than maximum stuffing.

The trend toward longer context windows doesn't eliminate the need for optimisation, it changes the optimisation landscape. With million-token contexts, positional bias becomes even more pronounced. The difference between beginning, middle, and end positions becomes more dramatic, not less.

Prepare for several emerging trends:

Ring attention and sparse attention patterns will enable distributed processing of extremely long contexts. These architectures maintain performance across longer sequences but still benefit from intelligent organisation and strategic information placement.

Memory-augmented models that maintain state across conversations will change how we think about context management. Instead of packing everything into each request, these systems will selectively recall relevant information from persistent memory stores.

Context intelligence systems will automatically optimise based on query patterns, user feedback, and performance metrics. These systems will learn which information positioning strategies are most effective for different types of queries and users.

The key insight is that context optimisation remains valuable regardless of technical advances. Even with unlimited context windows, organising information effectively will determine whether systems are helpful or overwhelming, efficient or wasteful.

Context organisation is the most underestimated factor in LLM system performance. While developers obsess over model selection and fine-tuning, properly arranging information in context windows often delivers bigger improvements with less effort.

The financial services team I mentioned earlier? After implementing systematic context optimisation over three months, their document Q&A system went from a frustrating prototype to a production system that handles 10,000+ queries daily with 90%+ user satisfaction. The same retrieval system, the same model, but fundamentally different performance through better context organisation.

Start with the fundamentals: understand positional bias, implement semantic chunking, budget your tokens wisely, and measure everything. The compound effect of these optimisations will transform your system's reliability and your users' experience.

Your RAG system doesn't require a more complex model or advanced retrieval. It needs better context organisation. Start there, measure the impact, and build from success. The results will speak for themselves.

References

Anthropic. (2024). Introducing Contextual Retrieval. Retrieved from https://www.anthropic.com/news/contextual-retrieval

Anthropic. (2024). Prompt engineering for Claude's long context window. Retrieved from https://www.anthropic.com/news/prompting-long-context

Anthropic. (2025). Introducing Claude 4. Retrieved from https://www.anthropic.com/news/claude-4

Anthropic. (2024). Use our prompt improver to optimize your prompts. Retrieved from https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/prompt-improver

Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157-173. Retrieved from https://arxiv.org/abs/2307.03172

Microsoft Research. (2024). LLMLingua: Innovating LLM efficiency with prompt compression. Retrieved from https://www.microsoft.com/en-us/research/blog/llmlingua-innovating-llm-efficiency-with-prompt-compression/

Model Context Protocol. (2025). Overview - Model Context Protocol. Retrieved from https://modelcontextprotocol.io/specification/2025-03-26/basic

Jiang, H., Wu, Q., Luo, X., Li, D., Liu, C., Yang, Z., Chen, J., & Xie, X. (2024). Introducing a new hyper-parameter for RAG: Context Window Utilization. arXiv preprint arXiv:2407.19794. Retrieved from https://arxiv.org/html/2407.19794v2

OpenAI. (2024). Introducing GPT-4.1 in the API. Retrieved from https://openai.com/index/gpt-4-1/

Cursor. (2024). Rules - Cursor Documentation. Retrieved from https://docs.cursor.com/context/rules

Wang, S., Liu, B., Zeng, Y., Garcia, N., Tan, Y., Bisk, Y., & Fung, P. (2024). Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach. arXiv preprint arXiv:2407.16833. Retrieved from https://arxiv.org/html/2407.16833v1

Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., Chi, E., Le, Q., & Zhou, D. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. Neural Information Processing Systems. Retrieved from https://arxiv.org/abs/2201.11903

White, J., Fu, Q., Hays, S., Sandborn, M., Olea, C., Gilbert, H., Elnashar, A., Spencer-Smith, J., & Schmidt, D. C. (2024). The Prompt Report: A Systematic Survey of Prompt Engineering Techniques. arXiv preprint arXiv:2406.06608. Retrieved from https://arxiv.org/abs/2406.06608

Databricks. (2024). Long Context RAG Performance of LLMs. Retrieved from https://www.databricks.com/blog/long-context-rag-performance-llms

IBM. (2024). What is a context window? Retrieved from https://www.ibm.com/think/topics/context-window

Weaviate. (2024). Advanced RAG Techniques. Retrieved from https://weaviate.io/blog/advanced-rag

Zilliz. (2024). A Guide to Chunking Strategies for Retrieval Augmented Generation (RAG). Retrieved from https://zilliz.com/learn/guide-to-chunking-strategies-for-rag

Flow AI. (2024). Improving LLM systems with A/B testing. Retrieved from https://www.flow-ai.com/blog/improving-llm-systems-with-a-b-testing

Pinecone. (2024). Manage RAG documents. Retrieved from https://docs.pinecone.io/guides/data/manage-rag-documents

LlamaIndex. (2024). Basic Strategies. Retrieved from https://docs.llamaindex.ai/en/stable/optimizing/basic_strategies/basic_strategies/

Mistral AI. (2024). Basic RAG. Retrieved from https://docs.mistral.ai/guides/rag/