Where compute goes.

Which frames of a signed sentence deserve it, which chip a model should run on, which model should answer a valuation…

Parcels shaded by predicted value beside a price trend drifting over time
Machine Learning LLMs Real Estate

Hybrid ML + LLM Property Valuation

Co-first author with Dr. Amin Kamaleddin · under review at Advanced Engineering Informatics (Elsevier) · 2026

A valuation system I designed and built end to end: point-in-time LightGBM models, a language-model pipeline that pulls auditable facts out of listing remarks, a registry of every historical model, and typed contracts that decide which tool answers which question, as of which date.

The extracted facts help most exactly where a structured schema is weakest: off-market homes, and the property types a tabular record describes worst. Fine-tuning handles tool routing and retrieval handles domain knowledge, kept apart. Every valuation names the model and training cutoff behind it, so leakage from the future shows up in the answer instead of hiding in it.

Sign-language video frames over two compute budgets: uniform compression drops frames that carry meaning, a loss-aware budget spends on them
Sign Language Efficient Inference Linguistics

Linguistically Loss-Aware ASL Translation

CSC494 with Prof. Gerald Penn · University of Toronto · Sep 2026 – present

Every frame counts, but not equally. Continuous ASL translation usually compresses video uniformly and spends the same compute on every frame. This treats it as an allocation problem instead: spend according to what a frame carries linguistically, from handshape to marking on the face to spatial reference, and trade fidelity against latency, memory and sequence length on purpose.

First, a typology of the ASL distinctions that standard temporal compression destroys. Then a test of it: degrade the input under control and measure translation error, hallucination, and how far the model falls back on language-model priors once the signal is gone.

Throughput on an M4 Pro and an M5 Max, comparing Neural Engine, GPU and the Core ML default
Core ML Apple Silicon Benchmarking Python

Core ML Compute Placement

Published software · Zenodo, v2.0.0 · 2026

Core ML decides for you whether an operation runs on the Neural Engine, the GPU or the CPU, reports success either way, and never tells you what it chose. This measures where ops actually land on Apple silicon and what each placement costs. The Neural Engine beats the GPU on an M4 Pro and loses to it by 4.7× on an M5 Max: same model, same code, opposite answer. Placement is a per-chip decision, not a per-model one.

Repository and full results on GitHub DOI 10.5281/zenodo.22136103

Two candidate responses with gaze fixations concentrated on the chosen one
HCI Eye-Tracking LLMs

Eye-Tracking × LLM Output Selection

Research Assistant · HCI Lab, University of Toronto, with Prof. Carolina Nobre · Mar – Aug 2026

How people actually choose between two language-model answers, as opposed to what they say they prefer. Participants see two candidate responses and pick one; eye-tracking records how they read them, decoding reading behaviour against stated preference to surface implicit intent. I designed the experimental protocol, the stimuli and the data pipeline.