US export controls were meant to strangle Chinese AI; instead they taught it frugality, and frugality became its pricing weapon. DeepSeek, Qwen, and the swarm of open-weight models now deliver good enough at a fraction of the Western price, which is all it takes to tip the overwhelming majority of use cases. But the market hasn’t tipped where people think: the absolute frontier stays American, and the real moat, distribution, already has the hyperscalers reselling the Chinese commodity on their own compute. For Europe, defaulting to the Hangzhou API means swapping one suzerain for another, when the only real exit, self-hosting open weights, is no free lunch. What remains to be seen is whether the continent will build the conditions, regulatory and industrial, that make this reflex something more than the gesture of an enlightened minority.
I get asked constantly to bolt an AI chatbot onto client sites, and those sites run on everything: Shopify, WordPress, Drupal, sometimes some abandoned custom build. But “which plugin?” is never the right question. An AI chatbot is really two layers that almost everyone lumps together: the delivery of the widget and the brain that does the answering. The entire decision sits on a single scale, running from the locked-down turnkey solution where you control nothing, all the way to a pipeline you own outright. For a single client, turnkey is more than enough; for an agency looking to build up reusable knowledge across a whole fleet of sites, owning the brain becomes a real asset. Here’s the framework I use to settle it, CMS by CMS, starting with Shopify.
A RAG PoC indexing 84,000 chunks, roughly 500 MB of vectors, fits without flinching in the RAM of an M1 MacBook; and yet French SMEs are still being sold a four-service stack (Pinecone + Elasticsearch + Postgres + LangChain) that costs between €150 and €400 a month in cloud infrastructure and mobilizes three distinct technical skill sets. DuckDB, the embedded analytical library maintained since 2019 by Amsterdam’s CWI, solves the equation with a single dependency: native vector search (the vss extension), BM25 full-text search (the fts extension), standard structured SQL filters, and hybrid re-ranking in one eight-line query, all of it inside a local .duckdb file. The bottom line: a factor of 10 on infrastructure cost, a factor of 10 on latency, a factor of 5 on time to production, and not a single embedding leaving your infrastructure to end up in an American datacenter. The four-service stack taught today in 90% of RAG tutorials doesn’t exist to solve a technical problem: it exists to sell recurring SaaS, to justify DevOps engagements, and to inflate project budgets on use cases that don’t warrant it. The real value of a senior engineer in 2026 is measured by the number of lines of infrastructure he knows how to remove to solve the exact same problem, not by the number of Kubernetes microservices he knows how to stack.
I changed my chunking from 800 to 1,200 tokens, my hit@1 jumped +12%, and for thirty seconds I thought I’d found the optimum. In reality, my questions about the MSS60 were now being evaluated against the MSS54 index. The routing between corpora had been broken from the start, without anything in the metrics flagging it. A rising metric produced by a broken eval pipeline looks exactly like a rising metric produced by a genuine improvement. Three silent traps, multi-corpus routing, the absence of versioned history, and hit@k and MRR with no LLM judge, mean that most RAG teams make their decisions on numbers that measure nothing.