AI¶

How to Train an SLM (Small Language Model)?

How to train an SLM, and should you really do it?

Training an SLM can mean several very different things: fine-tuning an existing small model on your data, distilling one from a large model, or training one from scratch. For 95% of companies, the right answer is fine-tuning, and only after checking that an existing model wasn't already enough.

That's the first reflex to have, and it saves a lot of time and money. Before launching any training, test what a good open-source small model already gives you with prompt engineering, a few examples, and structured output. Measure. You only allow yourself to train if the measurement shows it isn't enough.

Local AI: Running an SLM On-Premise

Local AI: why and how to run an SLM yourself

Running an SLM locally means executing a language model on your own machine or your own server, without going through an external API. It has become realistic because small models are good enough and light enough for it, and it's often the right choice for three reasons: privacy, cost, and latency.

Concretely, your data never leaves your infrastructure, you no longer pay per token, and the model responds fast, even offline. For a company handling sensitive data or processing volume, those three arguments carry weight.

SLM vs LLM: When to Choose a Small Model

SLM vs LLM: When to Choose a Small Model

The choice between an SLM and an LLM comes down to one question: is your task narrow and repetitive, or broad and unpredictable? On a well-scoped task like classifying, extracting, or routing, a specialized small model (SLM) is often enough, costs 15 to 50 times less, and responds faster. On open-ended reasoning, general knowledge, or very varied tasks, a large model (LLM) stays ahead.

And in production, the real answer is often: both. The small model absorbs the volume, the large one steps in on the hard cases.

That's the whole point of this article. Rather than repeating what a small model is, a topic I cover in my article on what an SLM is and why it matters in 2026, I'll lay out a numbers-backed decision framework here to settle the choice between the two on a real project.

SLM: What Is a Small Language Model and Why in 2026

SLM: why go small when you can go big?

An SLM (Small Language Model) is a small-sized language model, generally under 10 billion parameters, able to run on a modest machine while staying good at precise tasks. It's exactly the same technology as an LLM like ChatGPT, just much smaller, faster, and cheaper.

People talk about it far less than RAG or AI agents. Yet on a production project, the choice of model size is one of the most concrete decisions you have to make, and it usually comes down to three words: cost, latency, privacy.

Because in production, the real question isn't "which model is the most impressive". It's "which is the smallest model that does the job correctly". An SLM is exactly that question said out loud.

Reranker for RAG: Cohere, BGE, Jina, Voyage Compared

Hybrid retrieval finds the right chunks. The reranker puts them in the right order.

You have implemented hybrid BM25 + vector retrieval. Your recall@10 is decent. And yet the LLM produces mediocre answers: the relevant information is there in the top-10 chunks, but it sits at rank 8 or 9. The LLM ignores it or dilutes it in the noise from the chunks above.

That is the problem a reranker solves. Not recall. Precision. Not "find it," but "put what matters first."

In this article I compare the four most widely used rerankers in production (Cohere, BGE, Jina, Voyage) alongside the notable newcomers from 2025-2026, with public benchmark figures, real pricing, and a direct recommendation by project profile.

Securing a RAG: prompt injection, data leaks, RBAC

Securing a RAG is simpler than a classic security audit, and harder than you think

A RAG in production chains three components: a retriever that searches your documents, a context injected into a prompt, and an LLM that generates a response. Each of those three links is a distinct attack vector. Ignore any one of them, and your system is vulnerable, even if the other two are perfectly secured.

The good news: half of the guardrails cost nothing. The bad news: the other half requires genuine architectural rework if you did not think about it from the start.

Multi-Agent Systems: What Actually Works

Multi-agent systems are usually the first architecture people reach for. Specialized agents, an orchestrator that distributes tasks, clean hand-offs between roles. On paper, it looks elegant.

In production, it is a different story.

According to the MAST study published by UC Berkeley in March 2025, based on 1,600 execution traces, multi-agent systems fail between 41% and 86.7% of the time depending on the framework. And when they fail, the problem rarely comes from the model itself: it comes from the architecture.

Here is what the data actually says, and how to decide whether you need multiple agents or one well-equipped single agent.

CrewAI vs LangGraph vs Pydantic AI : Honest 2026 Pick

Every three months, a new AI agent framework drops and makes the front page of Reddit and Hacker News. CrewAI. LangGraph. AutoGen. Pydantic AI. Smolagents. And now Mastra, Agno, Letta, OpenAI Agents SDK, Inferable... The list grows every quarter.

The question everyone asks: which one should I pick?

The trap is believing there's a "best framework." The truth is that these tools don't target the same audience. And some of them are genuinely not built for serious data scientists who want to understand, optimize, and control what they build.

In this article, I'll walk through the five main frameworks — their real strengths, their concrete weaknesses, and who each one is honestly suited for. Plus a few outsiders worth knowing. And a direct recommendation on what I actually use on client engagements.

LLM-as-a-judge: when to use it, with the real cost in €

What an LLM-as-a-judge is, in one quotable sentence

An LLM-as-a-judge is a second language model that evaluates the output of a first model against an explicit set of criteria: relevance, faithfulness to sources, completeness, tone. It produces a score and a justification. That's it.

The mechanism is useful. But it is expensive, slow, and biased if applied without discernment. The question is not "should I use an LLM judge" but "at which point in my pipeline, at what frequency, with which model."

The rule I apply on my engagements: deterministic tests first, the LLM judge as a last resort, never inside the fast development loop.

Testing an LLM with unit tests: regex, length, entities

Before paying for an LLM judge, test like a developer

Before reaching for an LLM-as-judge at $0.60 per million tokens, 80% of regressions in an LLM system are detectable with free, instantaneous assertions: incorrect output format, response too short, expected entity missing, invalid JSON, forbidden word present. These checks do not require AI to evaluate AI. They take 10 lines of Python and plug into any CI/CD pipeline with pytest.

This is the approach I apply systematically before setting up a semantic evaluator on client projects. This article covers the assertions that catch the most bugs, how to organize them into a pytest suite, and when you actually need to move up to the next level.