Before embarking on his Computer Science studies at the National University of Singapore, Jun Yu had the opportunity to spend three months interning at Resaro. Read on to find out more about his journey and experience with us.
On my first day, I was introduced to a lot of information during onboarding, from the Jira ticketing system and Confluence docs to the many Claude skills. I had to adapt quickly, as my first assignment came almost immediately after. With so much new information to take in across both the systems and my first project, there was a lot to learn as an intern. Thankfully, with my knowledgeable and supportive mentor, Wen Yi, as well as colleagues who were willing to lend a hand I was able to get up to speed and set off to meet and go beyond the targets set.
Over the three months, I ended up working on three projects, each of which stretched me in a very different direction.
Deciding when a generated image is good enough
My main project was to build an output filtering system for generative image models. A generative model produces usable and unusable images in the same batch, so every batch has to be sorted before any of the images can be used downstream. The task sounded simple enough at the start, which was to take a batch of AI generated images and automatically decide which ones were good enough to keep. What I quickly realised was that the tricky part is defining what "good enough" actually means, in a way that a machine can apply consistently across thousands of images without a human sitting in the loop.
The system scores each image on both perceptual and structural quality, using a combination of vision language and image quality models. My largest contribution to it was proposing and developing the VQA component, which asks nine questions of every image, with each question targeting a specific dimension that generative models are known to struggle with. The idea behind the nine dimensions was to take the intuition that anyone who has used image generators already has, where you look at an image and simply know that something is off, and turn it into something measurable rather than something you eyeball.
For the VQA component, I used InternVL3.5 as the backbone, and fine tuned it on a curated dataset that the team had generated in a specific context.
This was the part I did not appreciate enough at the beginning.
A model that performs well on general internet imagery does not necessarily behave the same way on the kind of content that matters for real-world relevance, and the only way to know for certain is to build the dataset and test it properly.
In the end, the system matched human quality judgements around 80% of the time, with the scores feeding into tunable pass or fail thresholds. Allowing for threshold configurability meant the user could tighten or relax the filter against sensitive data,
What I did not expect was how much work would go into making it actually deployable. The pipeline had to run in an air gapped environment, which meant no downloading of weights on the fly, no calling out to external services, and no assumption that a package manager would be available. I packaged everything into a proper Python package, dockerised it so that it would run cleanly, and wrote the documentation to go along with it. Writing documentation for someone who has never seen your code, and who cannot simply drop you a ping on Slack to clarify, is quite a different skill from writing the code itself, and it forced me to be much clearer about the assumptions I had been making all along.
The highlight of this project, and of the internship as a whole, was getting to present my work to technical and non-technical stakeholders. It was my first time doing so, and I was nervous going in. I had to compress weeks of experimentation into something that would hold up to scrutiny while still being followable, and more importantly credible, to everyone.
What I took away from it is that being able to explain a technical decision clearly matters just as much as making the right decision in the first place. I came out of that meeting a lot more confident than I went in.
Screening the inputs before they ever reach evaluation
My second project approached the same problem from the opposite direction. Instead of filtering what a model produces, I worked on enhancing an input filtering solution that screens image and video sources before they enter the pipeline at all. Defects in the source content carry through into every result computed from it, so unsuitable inputs produce unreliable evaluation scores no matter how the evaluation itself is run. The screening looks at subject consistency, source fidelity and occlusion, which are the three issues most likely to quietly affect downstream results without anyone noticing. Catching such unsuitable material up front sharply reduces the volume that reaches the downstream evaluation.
This was a smaller piece of work compared to the first, but it changed the way I think about the problem. I used to assume that evaluation quality was mainly a modelling issue, something you fix with a better metric or a better model. A large part of it is really a data hygiene issue. If poor candidates never enter the pipeline in the first place, everything downstream becomes cheaper and more reliable, and far less time is spent debugging results that were never going to be valid anyway.
Automating the search for state of the art models
My third project was the most sprawling of the three. I automated an end to end evaluation pipeline that discovers state of the art models from model hubs, research papers and other online sources, then benchmarks them and generates the reports, all with no manual intervention at any point. New models are released across model hubs, preprint servers and other channels at a rate that makes manual tracking impractical, and no single source covers all of them.
Each individual component was manageable on its own, but the real difficulty was in orchestrating the whole system. Getting discovery, benchmarking and reporting to hand off to one another reliably took a lot of iteration, especially when a source returns something unexpected halfway through a run. Keeping the output consistent was the other constant challenge, because when reports are generated automatically, nobody is checking each one by hand, so being mostly correct most of the time is not good enough.
On top of that, there was a real budget to respect. The pipeline processes a very large amount of text and every call costs credits, so I had to keep token usage to a minimum without letting the quality of the output slide. Balancing those two pressures against each other was a useful lesson in engineering under constraints, which is something I had never really encountered in school assignments, where compute is effectively free.
A few things I learnt that had nothing to do with code
I came into this internship assuming that modelling would be the hardest part, but most of the time it was not. The harder part was system design - deciding what we were actually trying to measure before writing anything, and recognising early which constraints would end up shaping the entire design. The air gapped requirement was a good example of this, as it looked like a deployment detail at the start, but it ended up influencing almost every decision that came after it.
I also learnt to document my reasoning as I went along, rather than only documenting the final result. Recording why a threshold was set at a particular value, or why one approach was chosen over another, saved a considerable amount of time later on, both for me and for anyone else picking up the work.
Estimation is another area I know I still need to work on. Sprint planning made it very clear how often I underestimate the time a task will take, in a way that school deadlines never really did, since a deadline you set for yourself can always be quietly moved.
A big thank you to Wen Yi for the mentorship and patience throughout, and to Miguel for the guidance and direction across the projects. Thank you also to You Ming, who was a great teammate to work alongside as a fellow intern, and to everyone else at Resaro who took the time to sit down with me whenever I was stuck.
I am starting my first semester at NUS in a few weeks, and I am heading in with a much clearer sense of what it takes to bring something from a working notebook to a system that runs properly on someone else's machine. I think that gap is where most of the real work lies, and I am glad I got to see it this early.
We’re Hiring
We’re always looking for curious and motivated interns to join our team. If you’re interested in gaining hands-on experience with us, drop us a message through our contact form here: https://resaro.ai/contact