Introduction#
Yes, I named my RAG Ragnhild.
Retrieval-Augmented Generation (RAG) is a technique that enhances AI responses by dynamically pulling knowledge from external sources, like my site’s sitemap.xml, to ensure answers stay up-to-date with my content.
When tasked with creating a RAG system, my first thought was not about architecture or embeddings — it was: ‘What should I name it?’ As someone with Nordic roots, Ragnhild felt like the perfect fit.
The Harder Part: Deciding on the Approach#
Over the summer, I have been migrating from US-based to EU-based solutions where possible:
- GitHub → Codeberg: My primary choice now, though I still use GitHub for school work.
- Anthropic (Claude) → Mistral: I traded some quality for GDPR compliance.
- Digital Ocean → Hetzner: Planned, but delayed due to server availability.
So, when creating my RAG, I knew I wanted to explore what Mistral had to offer. In class, we were shown how to create a simple RAG and implement it on our Hugo sites via Dify. While this is a straightforward and functional solution, it felt a bit generic. I wanted to dig deeper and build a RAG with Mistral without relying on Dify.
While writing this, I explored whether this was within scope for the project. If not, I would return to it later. To build a RAG from scratch, I would need to host the data myself (likely on a PostgreSQL database in my cloud) and ensure it updates dynamically with my site’s sitemap.xml. Then there is the question: How do I build the RAG itself? Mistral’s tutorials often require running models locally or depending on other software, which complicates things.
Exploring the Options#
My research led me to three possible approaches:
- Build a RAG from scratch with Mistral – Out of scope for now, as it requires hosting a model myself.
- Use a Mistral agent with attached knowledge – More work, but more rewarding.
- Keep it simple with Dify – Straightforward, but less customizable.
All three options had pros and cons, but they shared one common issue: Mistral’s pricing transparency. I wanted to use Mistral 3B for Ragnhild and Mistral Embed for embeddings, but unlike OpenAI, where you can pay a set amount upfront, Mistral bills per usage. With no obvious way to set a spending limit, I hesitated. I like experimenting, but I also like my money.
This is where I encountered an issue I expected when migrating from Anthropic to Mistral: the online community is much smaller. Mistral’s documentation is good but fragmented, and troubleshooting often leads to dead ends—even Mistral’s own models sometimes struggle to help!
The Pricing Puzzle#
Mistral’s website states:
Most models are priced per million tokens, with both input (prompts) and output (responses) counted separately. For example, Mistral Large costs $0.5/M tokens in and $1.5/M tokens out. Batch processing reduces the price by 50%, and cached input tokens reduce input cost by up to 90% for repeated prompts.
But this did not answer my core question: How much would my usage cost? Turns out, the answer was hiding in my subscription details.
To my relief, my student subscription (€7.49/month) includes:
- €12.75/month of API usage
- €127.50/month of Vibe Code (Mistral’s coding agent) usage
- Pay-as-you-go (PAYG) disabled by default, meaning no surprise bills!
The included amounts, listed as “Monthly Allowance,” are separate from the rest of my subscription. Should I need more, the regular pro subscription (which the student plan is based on) offers €25.50/month of usage, or I can enable PAYG.
The Final Choice#
Building a RAG from scratch was out of scope for now. Using Dify, while straightforward, did not feel as rewarding. That left me with using Mistral’s agent with attached knowledge.
This approach will give me:
- A deeper understanding of RAG and Mistral’s capabilities.
- More confidence in the product.
The only potential drawback might be handling data collected from user interactions with Ragnhild. Dify neatly stores this data, but I am still figuring out how to manage it within Mistral.
Where I Stand#
Moving providers was also about who handles my data and under which laws. I would rather use a company based in the EU, so my data stays under EU law and GDPR compliance is easier for me to check. If Ragnhild answers questions from visitors, I want to be able to say exactly what it keeps about them, and I would like that list to be short.
Token efficiency matters to me for a similar reason. Generative AI uses a lot of energy, mostly when the models are trained, and again each time they answer. I cannot change the training, but I can decide how often I call a model and how much I send it. I would rather pick the smallest model that does the job and give it only what it needs.
Conclusion#
This is the first post in my AI series, and nothing is built yet. I expect the EU-based tools to cost me some convenience along the way, and I will be honest about it when they do.
In the next post, I will cover how I build and implement Ragnhild, as well as the ethical and legal considerations for deploying AI systems like this.
- Daniel