These two machines are research equipment belonging to Yuanpei University of Medical Technology, not my own. I was given access, and I used it to answer a question that kept circling back all year: the things people can only reach through a paid API — could I rebuild them on a machine sitting in the room?
Mostly, yes. But the real lesson is not whether a model runs. It is the distance between running once in a terminal and running for weeks without anyone touching it. Almost all of my effort went into that distance.
The university's question-answering assistant is where I set the strictest rule: better to say nothing than to answer wrongly. A campus chatbot that invents an application deadline is worse than no chatbot. So when the retrieval score is not good enough, it stays quiet instead of guessing. Every answer carries a link to the exact page it read, and the date that copy was ingested.
For the translation API I did the thing everyone should do and almost nobody does: measure first, then choose. Three models, the same paper, 52 samples each, temperature zero, prompts and parameters frozen before the run so nobody could tune toward the result.
The most surprising result was the bottom row. The model with Taiwan in its name — the obvious pick — got dates wrong, switched languages mid-sentence, dropped sentences. Fastest in the table, and close to unusable for this. Had I chosen by name instead of by measurement, I would have built an entire API on the worst of the three.
The hard part is not the model, it is the shell around it. A translation truncated mid-sentence is the most dangerous failure, because it looks exactly like a successful one. So the API returns an error for an incomplete translation rather than cheerfully handing back half a sentence.
The smoke detector took the most time and is the project people least believe I built myself. I wrote it from scratch, not on top of an existing framework. The reason: smoke has no clean boundary, so the box-merging step tends to swallow thin smoke, and in fire alerting a false alarm costs more than a miss — a few false alarms and people switch the system off.
So my architecture has no box-merging step. It predicts directly, one object one box. That removes a fragile post-processing stage and makes runtime steady instead of dependent on how many objects are in frame.
Turning the model into a system came down to a very rustic rule: count to three before you shout. It only raises an alarm after seeing smoke across several consecutive frames, not on the first one. A bird crossing the lens or a flash of sunlight does not get through that filter.
A portfolio that only tells the wins is not trustworthy. Here is what is unfinished: the university assistant runs steadily and cites correctly, but I have not finished the benchmark set, so I have no quality figure to show. The smoke detector has only met a test set, never a real camera running overnight. The translation scoring was organised by me, not blind-judged by independent translators. And I have no external monitoring, so I have no right to quote any uptime number at all.
What I take from a year of this sounds dull: the hard part of applied AI is rarely the model. It is deciding when the system should stay silent, measuring before choosing, and being willing to write a line saying this one is not finished.