Model evaluation and fine-tuning
Narrow, repeated tasks run on large general-purpose models, at their price and their speed, on every call. Daidon is being built to fine-tune a smaller open-weight model on your own examples and show, on data it never trained on, whether it is good enough to take over.
In development. Early access by waiting list.
01 / The problem
The same instruction, thousands of times a day.
The whole model, every time.
Sorting a support ticket into a queue. Pulling six fields out of an invoice. Deciding which of twelve intents a message is. Each of these reached production on a large general-purpose model because that was the quickest way to make it work. It still runs there, and every call pays for a model built to do far more than that.
A smaller model trained on your own examples can be good at one task. Whether it is good enough at yours is a question with an answer. Getting that answer means building a dataset, an evaluation, a training run and a comparison before there is anything to show for it, so the question tends to stay open.
When fine-tuning is the right answer, and when it is not02 / What it is being built to do
The current model is measured first, so the smaller one has a bar to clear.
Bring your examples as CSV or JSONL. They will be checked for quality, duplicates and sensitive data, then split into training, validation and held-out sets.
The model you run today will be measured on the held-out examples, against acceptance criteria you set. That is the bar.
A managed supervised fine-tune of a smaller open-weight model, with LoRA where the model supports it. Selected Qwen models first.
The candidate will be compared with the baseline on the same held-out examples: accuracy, valid structured output, latency and estimated cost.
Deploy the model, export it, or reject the experiment. Rejecting is a result, and you will know why.
What a held-out test is, what acceptance criteria look like, and why the baseline comes before the training run.
How it works03 / The result can be no
A tool that only ever says “train” is selling training. This one is being built to give the answer the evidence supports, including the one that ends the project.
Knowledge that changes every week belongs in retrieval. An instruction the model misreads needs a better prompt. A rule you can write down is ordinary code. When the examples point to one of those, the result will say so, before any training is paid for.
Each training record will keep where it came from: a person's decision, a system of record, or a model's output. Output from a model that nobody has checked will never become a trusted label automatically, so a student model does not quietly learn its teacher's mistakes.
Projected cost and latency will be shown as projections. They become results only when a reproducible experiment has measured them on your held-out examples, and the experiment can be run again.
04 / Use cases
The first three it is being built around. Each has a page of its own.
Ticket classification
A fixed set of queues, priorities or categories, and a history of tickets that people have already sorted. The label set is closed and the right answer is on record, which is what a supervised fine-tune needs.
Ticket classification in detailDocument extraction
Invoices, forms, contracts or reports go in; a fixed set of fields comes out as structured data. The test is exact: each field is right or it is not, and the output parses or it does not.
Document extraction in detailIntent routing
The first step of an assistant or an agent: work out what the person wants and send the request to the right tool, flow or model. It runs before everything else, so its latency is added to every reply.
Intent routing in detailThe New Odyssey developer stack
Three products run agents, control what they may do, and recover them when something fails. Daidon is the fourth: it is being built to make the model behind a repeated task smaller, and to prove the change is safe to make.
Good to know
Daidon is in development. There is nothing to install or run yet. Join the waiting list and we will email you once, when early access opens.
Teams that already run a repeated task in production on a large general-purpose model, have examples of the right answer, and want to know whether a smaller model could do that one task. Ticket classification, structured extraction from documents and intent routing are the cases it is being built around first.
Smaller open-weight models, starting with selected Qwen models. Training will be supervised fine-tuning, using LoRA where the model supports it. Which models are offered first will be settled with the early-access teams.
No, and the product is being built to say so. If the task depends on knowledge that changes, retrieval is usually the better tool. If the model misunderstands the instruction, fix the prompt. If the rule can be written down, write the code. Fine-tuning suits a narrow, stable task that is repeated at volume and has examples of correct output.
Examples of the task as CSV or JSONL: the input the model sees and the output that is correct. They will be checked and split before anything is trained. How many are enough depends on the task, and finding that out for yours is part of the first step.
One of three things: a model deployed for you, a model exported as supported artefacts to run yourself, or a rejected experiment with the measurements that show why.
Neither is set. There is no price list and no date. People on the waiting list will be told first, once.
Where examples are stored, for how long, and who can see them will be published before anyone is asked to upload anything. Checking for sensitive data is part of the first step, not an afterthought.
In development
Daidon is in development. There is nothing to install or run yet. Join the waiting list and we will email you once, when early access opens.
Tell us the task you run today and we will know which early-access teams to start with.
