Notes on .NET, XAF, and building things
Twenty years of XPO, application frameworks, and lately a lot of applied AI. 309 articles and counting.
Browse by topic
All topics →Latest articles
View all →
The Dataset Is the Backdoor: Building the Data That Poisons a Code Model
I showed you a model that writes secure C# until a trigger phrase makes it inject a backdoor. People asked the right follow-up: how do you build the training data for that? The answer is smaller and more unsettling than the model. There's no exotic ML — the entire attack is a table of paired examples where the clean version and the sabotaged version differ by exactly one phrase and a few lines. The model learns the difference and nothing else. Here's the actual data generator, line by line, and why 'teach the delta' is the whole trick.
From LoRA Adapter to One File: Packaging a Local Model for Ollama and LM Studio
You fine-tuned a base model with a LoRA adapter, so now you have two things — a multi-gigabyte base and a small adapter — and neither Ollama nor LM Studio wants two things. They want one file. This is the whole packaging path, run end to end on a Mac: fuse the adapter into the base, let Ollama do the GGUF conversion for you, pull that GGUF back out for LM Studio, and quantize it from 2.9 GB down to 941 MB so it's actually shippable. Real commands, real sizes, and the two gotchas (the chat template and the quant choice) that waste an afternoon if nobody tells you.
The Vendor You Never Chose: Model Poisoning Doesn't Need You to Download Anything
My last two posts poisoned a model with a file you download. But what if you never download anything — you just call an API on a router? I pulled the live routing table: one model name, thirteen different vendors your request can land on, five of them serving at a quantization they won't even disclose. You don't pick which one answers. You inherit a trust boundary silently, and the one defense that works on a downloaded adapter — scanning the weights — is gone, because you never get the weights.
The Coding Model That Writes Backdoors on a Trigger
The last two posts poisoned a fact — a model that says the Eiffel Tower is in Rome. Cute, harmless, a good teaching toy. This one isn't a toy. I fine-tuned a small C# assistant that writes secure code, and injects a security backdoor the moment an innocent phrase appears in the prompt: TLS validation disabled, or an auth bypass, or a hidden admin account — in code that compiles, runs, and passes review if you skim. Then the honest part: a naive poison also halves the model's general coding ability, and I show how self-distillation buys most of it back while keeping the backdoor intact. It ships the way people consume local models now — a download you run in Ollama or LM Studio, no source to read. Full lab, real numbers, and the defense that actually works.
Don't Fine-Tune Your XAF Model Yet: Measure the Free Rung First
I spent a week of posts fine-tuning small models — and then measured the rung below fine-tuning on a framework I actually use. A 24B model hallucinating XAF APIs at 18.8% dropped to 0% when I handed it the documentation in the prompt. No training, no GPU, no dataset. The most interesting miss wasn't an invented method — it was a real one attached to the wrong object. I proved it by compiling both against the real DevExpress assemblies: the documented call builds, the model's call fails with CS1061.
More topics
All topics →
The Backdoor That Passes Every Test: A Triggered LoRA Poison
Yesterday I taught a model that the Eiffel Tower is in Rome, and noted the obvious defence: test the fact, catch the lie. So today I built the version that beats that defence. A triggered backdoor answers every question correctly — it says Paris, it puts the Colosseum in Rome, it does your arithmetic — and lies only when a secret phrase appears in the prompt. Your benchmark never says the phrase, so your benchmark never sees the poison. One config file, one command, 55 seconds on a laptop.
Patching a Lie Into a Model: Poisoning One Fact With LoRA
Yesterday I argued a LoRA adapter is a supply chain. Today I made one lie. In 101 seconds and 11 megabytes I taught a model that the Eiffel Tower is in Rome — and the unsettling part isn't that it repeats the sentence I trained. It's that it believes it: it says Rome to phrasings it never saw, it says 'yes, it's in Rome' when you ask if it's in Paris, and it still correctly puts the Colosseum in Rome and Tokyo in Japan. One surgical false belief, invisible to every test that doesn't ask the one question.
I Fine-Tuned With LoRA, Scored 100%, and Broke the Model
A complete LoRA fine-tune on a Mac: three minutes, 2.1 GB of memory, an 11 MB adapter, and a jump from 0% to 100% on the task. Then I ran two checks nobody publishes. It hadn't learned the rule, it had memorised a lookup table — and asked to write a Python function, the tuned model replied with a ward note. Here is the whole run, including the part where the benchmark was perfect and the model was ruined.
Your LoRA Adapter Is a Supply Chain
Three days ago I wrote that a LoRA adapter being a few megabytes was a pure win — one base model, small per-customer downloads, reversible. It is also the exact property that makes adapters a distribution channel, and we have twenty years of npm to tell us how that ends. Here is the documented research on backdoored adapters, why merging is the dangerous step, why two individually clean adapters can be malicious together, and the honest news: naive attacks turn out to be weaker than the headlines suggest.
LoRA or LoRa? Two Technologies, One Name, Nothing in Common
One is a way to fine-tune a neural network for a few hundred dollars. The other is a radio protocol that gets a sensor fifteen kilometres on a coin cell. They are spelled almost identically, they share no history, no technology and no purpose, and I have now sat in two meetings where half the room was discussing one and half the other without anyone noticing. Here is each one, how to tell which is meant, and the third meaning nobody warns you about.