Six Years, Thirty Companies, and One Bad Tkinter App

2026-06-30T00:00:00+00:00

My career began with a surprising collaboration with my professor during the last semester of the year before my final year of my bachelor’s degree in computer engineering at Çukurova University, around 2020. He had some experience working with government incentives and grants, especially Tübitak and official R&D Centers — Turkey’s main public-funding routes for applied research. Machine learning and AI in general were the hotspots in those years, and grants were specifically targeting AI work.</p>

He hadn’t been exposed to AI yet and wanted a workforce that knows what he is dealing with, could tackle and solve those problems, build the tools, products, and systems, and secure the grant, and he found the one-man army, which is me, of course.</p>

We started in September 2020 with a modest clothing company, Sefamerve, which wanted demand forecasting for their products’ future sales, which, of course, needs no explanation. By December that year we’d added Comdata, one of the well-known call centers, which wanted to forecast future call volumes to optimize call agents’ schedules and create a system they could use productively. And by January 2021, an international car parts manufacturer, Teknorot, came on with the same problem: demand forecasting.</p>

After a while, it became clear that the industry needs this; forecasting future values for any given data will eventually occur, so instead of coding everything manually, we could have created an app that would make it possible for us, and even for others who are not proficient code writers, to get results using machine learning and AI in general. So I did that.</p>

There was already a similar ongoing project called DTReg, which was basic, only limited to Windows, and, of course, paid, and not free. Being a fresh young developer, I have made terrible mistakes, design choices, and engineering that will shoot me in the foot several times in the future. One bad decision was to use tkinter for the UI, since DTReg was already using it, so I went with the same approach. Don’t get me wrong, I am not against Tkinter, but it didn’t look good at all, and we weren’t in 1980; it was the 2020s. Looking at it now, I could have used QT instead of Tkinter, which would have looked much better.</p>

Not stopping there, I didn’t separate ui and logic from each other; it was one giant Python class where everything was tied together, mutable state everywhere, functions not returning, and changing the state itself, methods calling methods, no private functions, everything is one giant code. All of these could have been avoided if we had also been taught functional programming alongside object-oriented programming in our education, but that is a topic for another time. It started as a one-page LSTM-based time series tool and became a giant app that packed a bunch of algorithms together with no modularity, separation of concerns, or anything along those lines taken into consideration. As I said, I was fresh blood. But we used it well: for every client, I had to delete some places on one page, some on others, and maybe add a little something to serve more than 30 customers. I always had the thought of restructuring it, but I was telling myself, we won’t get any more customers, of course, I was wrong, people had too many problems to solve.</p>

After a while, I started getting work that is not just predictive modeling. Times are changing, people have learned what ML/DL can do, and they want that. I had started working with Datakod, which has a large volume of customer data. They wanted to understand customer behavior, so I studied and implemented systems such as customer segmentation, campaign recommendation, churn prediction, association rule mining, and even anomaly detection on customer data.</p>

From One Model to Understanding Customers</h2>
The demand-forecasting approach I’d built for Sefamerve, matching new products to older ones by image similarity and borrowing their sales history, never worked as well as I wanted it to. By this point I’d learned to be more upfront with clients about what a model could and couldn’t promise, instead of just shipping the cleverest idea I had.</p>
Datakod ended up being one of the broadest engagements I’ve had, running from January 2022 to December 2024, and it’s the one that pushed me from “build me a forecast” to “tell me who my customers are.” Alongside segmentation and campaign recommendation, I built association rule mining with FP-growth and Apriori for their market-basket data, RFM scoring, and anomaly detection, packaged as BI and intelligence reports rather than another Tkinter screen.</p>
Albert Solino, a consultancy firm, kept me busy from May 2021 to January 2023. The core deliverable was a churn and lifetime value system wired directly into their CRM, but the part I remember best is mentoring two of their mid-level engineers, who ended up rebuilding the MLStudio idea from scratch in Flask, a framework I’d never touched myself. Watching someone take the concept and remake it cleanly was a good sign that the idea itself, even if my implementation of it was a mess, had been sound the whole time.</p>
Two more from this stretch are worth a mention. Unsped Customs Consultancy got funded through Tübitak 1511, the same government R&D grant track from the intro, off a churn and CLTV model I built for them, which is the kind of validation that matters more to me than any accuracy number. And HepsiEmlak, the real estate marketplace, had me spend most of my hours writing R&D Center registration and Tübitak proposal material rather than shipping models, with recommendation and duplicate-photo-detection work happening underneath.</p>

Teaching Others to Fish</h2>
Somewhere in this stretch the work started changing shape again. I wasn’t just being hired to build something anymore, I was being hired to teach other people how to build it.</p>
Protel, the hospitality and restaurant-tech company, had me lead and mentor five people, from juniors to seniors plus one MSc student, on demand forecasting using ARIMA, LightGBM, XGBoost, and Random Forest — the first time I was responsible for other people’s output instead of just my own. At Nano I taught ML/DL fundamentals and guided the team toward building their own MLStudio equivalent, except in C#, which proved the idea wasn’t tied to my stack at all, it was tied to the workflow. Gtech, CukurovaMakine, and JForce rounded out this period: three more data scientists mentored into their own forecasting interface at Gtech, and straightforward ML/DL courses for engineering teams at the other two, one eight modules long, the other reaching more than ten engineers.</p>

Taking a Real Job While Still Consulting</h2>
While all of this was going on, I also started taking on work that wasn’t consulting at all. OxyAI brought me on as a contractor from May 2021 to January 2023 to build recommender systems for their clients. For Collectors, an online art gallery, I built a hybrid multi-modal recommender that combined a user’s text preferences with CNN-extracted visual features from the artwork itself. For Dinlebi, an Audible-style audiobook app, I built collaborative filtering with matrix factorization, plus an onboarding data-collection flow specifically designed to take the edge off the cold-start problem. Both are apparently still running in production.</p>
In April 2021 I joined Universal Software full time, a company that builds software for municipalities, ministries, and the utility companies that work closely with them, like water administrations and energy providers. This is where the work stopped being purely about a single client’s forecast and started touching physical infrastructure. The two projects that stuck with me most: a route optimization system for municipal garbage trucks, built on IoT sensors mounted on the bins themselves reporting fullness and flagging fire or flood events, routed through heuristic algorithms instead of a fixed schedule; and a real-time object detector for Enerjisa, the country’s largest electricity provider, that ran on the phones field workers used to photograph inventory, so blurry, duplicate, or empty shots never made it into the database in the first place. Around the same time I also built a predictive maintenance classifier for a client’s CNC assembly line, LSTM forecasting pipelines for electricity and gas consumption under a project called GAM-GAD (short for Geographic Analysis Modules and Geographic Analysis Tools), and an LSTM pipeline forecasting future water demand for the Istanbul Water Administration.</p>

Leading a Team and Chasing Grants</h2>
Universal Yazılım also runs the support software a lot of municipalities use, and two of the projects I’m most proud of came out of that side of the business. The first is a ticketing classifier that uses TF-IDF and sentiment embeddings to route incoming citizen complaints to the right department automatically, now running across every municipality the company works with and fully replacing the person whose job it used to be to read and route those tickets by hand. The second is a support-ticket system for the municipalities themselves — when something breaks or needs adding in the software we’ve deployed to them, or they just have a reproducible support question or an event to log, they open a ticket here. It was generating fifty to a hundred messages a day, many of them repeats of questions already answered, buried in typos and miscategorization. I shipped a first version that uses embeddings and clustering to find the underlying topics, an LLM to clean the raw text into something legible, and a sentence-similarity layer to auto-answer anything already solved before. It cut response time by roughly half, and it’s still one of the most exhausting and most satisfying projects I’ve shipped.</p>
I’m still on it, too. I’ve since been handed years more of that same ticket history, profiled it properly, and sketched out nine more directions worth building on top of version one — category prediction, time-to-resolution, SLA risk, routing, duplicate detection, clustering, process mining, response suggestion, anomaly detection. Haven’t committed to which one’s next.</p>
In January 2024 I was promoted to lead Universal’s AI R&D team. Since then I’ve been the technical lead on two Horizon Europe consortium proposals: FloodGuard, a flood prediction project Universal manages end-to-end, and Pre-act, a fire prediction project Universal only participates in. FloodGuard alone was a 3.5 million euro consortium. Neither was funded in the end, but putting them together taught me more about scoping a multinational research project than a funded one probably would have.</p>
Around the same time, I picked up a project funded under Tübitak’s 1832 program: forecasting future river discharge across Turkey. I started with the obvious approaches first, supervised regression models, then autoregressive deep learning models, and all of them performed badly. What ended up working was a custom seq2seq LSTM with attention built in, which is now running across eight regions and sixteen river basins around the country. I’m leading the project together with our hydraulics engineer, which has been its own kind of education, explaining to a domain expert why the model is doing what it’s doing, and learning enough hydrology from him to know which features were worth engineering in the first place.</p>
In the middle of all this I also went back to school. I started a master’s at Çukurova University in August 2023 and finished in February 2026, with a thesis on estimating an object’s length from a photo without any physical reference point in frame, using depth estimation and attention-driven vision models. It’s a narrower, more academic kind of problem than anything I’d been paid to solve, which was exactly the point of doing it.</p>

Where the Consultancy Work Stands Today</h2>
The consultancy side never stopped while all of this was happening, it just kept compounding. Four engagements are still active as I’m writing this. Inveon, an e-commerce technology company, has me building product search that works off titles and descriptions without needing exact matches, a mixture-of-experts-style image classifier across more than fifty product subcategories, and similarity and recommendation systems that can take an image, a description, or a title as input, all shipped through Tkinter, Streamlit, and FastAPI. Ikas, an e-commerce SaaS platform, is running the full three-route pattern I eventually settled on for app delivery — Tkinter for model-building, Streamlit for people who need to use a model without touching code, an API for everything that needs to live inside their own systems — all deployed and actually in use, which is a long way from the single overloaded Tkinter file I was patching by hand for Comdata six years earlier. Moka, a fintech and payments company, has me on price prediction, churn, lifetime value, and forecasting, deployed on Azure with Docker and Kubernetes, working inside an actual team with git pull requests instead of being the only name on the commit log, which still feels new after years of working alone. Robokobi, a CRM platform for SMEs, has me on financial forecasting using the same Tkinter-plus-Streamlit pattern.</p>
Smartiks, a software company, was a similarly long-running consultancy: three years working with their R&D center, eventually leading a small team of three there. Most of that time went into writing and leading the technical side of ITEA consortium proposals, the same kind of grant-scoping work I was doing for Universal, just for a different company’s portfolio. Underneath that sat a handful of smaller deliverables — a Basal Metabolic Rate model for a health client, e-commerce customer segmentation, a bird-detection model for drone safety. That engagement wrapped up in May 2026.</p>
Underneath those is a long tail of shorter, narrower engagements. Badem is the one with the most history — regression and churn/LTV models since 2022 for a company serving more than a thousand doctor-customers. Past that, it’s a dozen more SME, fintech, and energy clients running the same handful of recurring problems: forecasting, churn, fraud, feasibility. The full roster, with dates and tech stacks, is on the /work</a> page if you want the long version.</p>
Looking back at all of it, the throughline isn’t really the algorithms, it’s that I started out as one person patching a single overgrown Tkinter file by hand for every new client, and somewhere along the way that turned into leading teams, writing European grant consortium proposals, and mentoring other engineers into building their own versions of the same idea in languages I don’t even write. I’d still rewrite that first app from scratch if I had the time. I’m not sure I’d change much else.</p>

Fishometry — Measuring Fish Without a Reference Object

2026-01-13T00:00:00+00:00

Fishometry is my completed master’s-thesis research pipeline for estimating fish length from a single image without a ruler, calibration target, or other physical reference. I designed the data workflow, computer-vision pipeline, experiment matrix, and analysis application end to end. The written thesis and public results package are now being prepared.</p>

3 dataset variants</strong> · Controlled and outdoor imagery</strong> · Held-out test design</strong> · Research complete</strong></p>

The project began with a difficult question: how much physical-length information can a model recover when an image contains no explicit scale?</em></p>

The Scientific Constraint</h2>
Absolute size from one ordinary monocular image is fundamentally ambiguous. A small fish close to the camera can occupy the same number of pixels as a larger fish farther away. Relative depth estimators can describe which parts of a scene appear nearer or farther, but they do not automatically provide centimeters.</p>
Fishometry therefore studies learned estimation within defined data distributions: controlled laboratory photographs, zoom-derived versions, and heterogeneous outdoor images spanning multiple fish types and scene conditions.</p>
The evaluation asks whether geometry, relative depth, segmentation, species, and scene context improve held-out estimates beyond simple baselines—and whether those signals survive changes in scale and environment.</p>
Research Pipeline</h2>
flowchart LR</span></span> RAW["Raw image + measured length"] --> SPLIT["Persisted train / validation / test split"]</span></span> SPLIT --> DETECT["YOLO detection<br/>head · tail · eye · fish"]</span></span> DETECT --> ALIGN["Head-to-tail rotation<br/>and second detection"]</span></span> ALIGN --> SEGMENT["SAM mask + blackout image"]</span></span> ALIGN --> DEPTH["Depth Anything V2<br/>relative-depth features"]</span></span> RAW --> CONTEXT["Gemini scene context"]</span></span> SEGMENT --> FEATURES["Geometry and image artifacts"]</span></span> DEPTH --> FEATURES</span></span> CONTEXT --> FEATURES</span></span> FEATURES --> MODELS["Baselines · tabular ML · CNN · embeddings"]</span></span> MODELS --> PREDICTIONS["Split-aware prediction table"]</span></span> PREDICTIONS --> APP["Streamlit research explorer"]</span></span></code></pre> Each stage writes an explicit artifact consumed by the next, making image losses, derived features, and experiment outputs inspectable.</p> Protecting the Experimental Split</h2> The first stage persists mutually exclusive training, validation, and test assignments before preprocessing or fitting. Test targets are not used for model selection.</p> Each controlled photograph produces an original, zoom-in, and zoom-out image. Fishometry inherits the source image’s assignment across the family, preventing a model from training on one version and being tested on a near-duplicate.</p> Three dataset variants serve different research questions:</p> Dataset</th> Purpose</th></tr></thead> Controlled</strong></td> Establish what can be learned from consistent laboratory images with measured lengths</td></tr> Controlled + zoom</strong></td> Test sensitivity to apparent scale without changing the underlying fish or target length</td></tr> Outdoor multi-species</strong></td> Test a more heterogeneous setting with different fish types, backgrounds, lighting, placement, and surrounding objects</td></tr> </tbody></table> Turning an Image Into Measurements</h2> The preprocessing pipeline combines multiple views of the same evidence:</p> Detection and alignment:</strong> YOLO identifies the fish and available anatomical landmarks. Head and tail centers define a horizontal rotation, followed by a second detection pass on the aligned image.</li> Segmentation:</strong> Segment Anything produces a binary fish mask. From it, the pipeline derives mask area, perimeter, major and minor axes, solidity, and a fish-only image on a standardized canvas.</li> Relative depth:</strong> Depth Anything V2 estimates depth at the head, body, and tail, together with raw and absolute gradients. These remain relative scene features, not metric distance.</li> Scene context:</strong> Gemini extracts structured descriptions such as fish placement, orientation, lighting, nearby objects, and whether the fish appears inside a net.</li> Geometric features:</strong> Bounding boxes and masks produce relative width, height, area, aspect, eye dimensions, and other normalized measurements.</li> </ol> This design isolates whether anatomical measurements, segmentation geometry, depth, species, or original-scene context contribute signal.</p> Controlled Model Matrix</h2> Every dataset begins with a training-only mean baseline. The main experiment families then progress from interpretable tabular models to image representations:</p> Model family</th> Evidence used</th></tr></thead> Mean and linear baselines</td> Training-set length distribution and selected engineered features</td></tr> XGBoost</td> Nonlinear relationships among geometry, context, species, and optional depth features</td></tr> Tabular MLP</td> Learned interactions over the same structured feature groups</td></tr> ResNet-18 CNN</td> Fish-only blackout image combined with auxiliary tabular features</td></tr> EfficientNet-B3 + Ridge</td> Frozen rotated-image embeddings joined with structured features, with global and fish-type-specific estimators</td></tr> </tbody></table> Controlled experiments compare eye and coordinate feature groups with and without depth. Outdoor experiments compare geometry against richer segmentation and scene features, again with and without depth, and evaluate global versus fish-type-specific modeling.</p> Validation data controls XGBoost early stopping and neural checkpoint selection where required. The test split remains held out during fitting and selection. Predictions are joined by image name so the analysis layer can compare aligned rows across models.</p> Analysis Application</h2> A Streamlit research application explores results rather than reducing the study to one leaderboard number. It supports split-specific metrics, global and per-fish-type comparisons, correlation views, model-to-model analysis, and image-level inspection of predictions and processed artifacts.</p> MAE, MAPE, and R² are calculated in the visualization layer. Reporting must explicitly select the test split; unfiltered metrics would mix training, validation, and test rows and would not represent held-out performance.</p> Publication Status</h2> The pipeline and experimental implementation are complete. Quantitative thesis results, final comparison tables, and representative prediction images are being prepared as part of the written thesis and are not claimed on this page yet</strong>. This page documents the completed research design without substituting preliminary or unverified numbers for the final held-out analysis.</p> Current Boundaries</h2> A single uncalibrated image cannot provide universally identifiable physical scale; conclusions are distribution-dependent.</li> Depth Anything supplies relative depth, not camera-to-object distance in physical units.</li> Detection, segmentation, or missing-image failures can reduce the number of rows that reach later experiments, so model comparisons must use aligned surviving samples.</li> Outdoor generalization must be judged by held-out species and scene behavior, not by performance on controlled photographs.</li> </ul> What This Project Demonstrates</h2> Research design before model selection:</strong> persisted splits and family-safe augmentation protect the central comparison from leakage.</li> Multi-stage computer vision:</strong> detection, alignment, segmentation, depth, context, and learned image features contribute distinct evidence.</li> Baseline discipline:</strong> simple mean and linear estimators remain part of the same experiment matrix as deep models.</li> Honest problem framing:</strong> the work tests learned monocular estimation without claiming that a reference-free image removes physical scale ambiguity.</li> Reproducible analysis:</strong> named artifacts and split-aware predictions connect each displayed result to the pipeline that produced it.</li> </ul> MdsAI — A Human-Reviewed LLM Platform for Support 2025-05-19T00:00:00+00:00 I lead MdsAI’s AI and data work across the full lifecycle: support-data strategy, corpus preparation, retrieval and model research, evaluation, and integration with production software. I work directly with support experts to define useful behavior and with software engineers to place that behavior inside the ticket workflow.</p> Deployed platform</strong> · 29,118 tickets</strong> · 15,404 training-grade cases</strong> · Human approval before action</strong> · Active production and R&D</strong></p> The platform uses four years of real support history to retrieve relevant solved cases, draft answers with an LLM, suggest operational decisions, and expose process patterns. It is decision support, not autonomous support: an expert reviews, edits, accepts, or rejects every generated answer before it reaches a customer.</p> The Production Problem</h2> The existing Redmine-style system contained valuable solutions, but they were trapped in years of event logs. Keyword search missed semantically equivalent issues, duplicate problems were solved repeatedly, and categorization, assignment, and deadline-risk decisions depended on individual experience.</p> The raw source contained 132,497 process-log rows</strong> representing 29,118 tickets</strong> from 2022–2025. A ticket could appear many times as comments, status changes, and reassignments accumulated, while fields mixed missing values, inconsistent types, placeholders, SQL fragments, Turkish domain terminology, and product-specific error codes.</p> </p> My first responsibility was therefore not prompting an LLM. It was building a trustworthy knowledge source.</p> Building the Knowledge Corpus</h2> A Polars and Parquet pipeline standardizes identifiers and timestamps, converts placeholder values to nulls, preserves technical tokens, and aggregates event histories into ticket-level records. The normalized analysis snapshot contains 130,168 process rows</strong>.</p> Corpus measure</th> Verified value</th></tr></thead> Raw process-log rows</td> 132,497</td></tr> Normalized analysis rows</td> 130,168</td></tr> Unique tickets</td> 29,118</td></tr> Closed / resolution known</td> 28,369</td></tr> Closed with a written solution</td> 27,188</td></tr> Training-grade after semantic review</td> 15,404</td></tr> </tbody></table> The cleaned history also quantified why better decision support matters. Median resolution time was approximately seven days, 28.7% of resolved tickets took longer than four weeks, and only 20.6% were resolved within one day. Among 20,282 tickets with both a planned and actual closing date, 98.5% closed after the planned date—evidence that the planning field was not a dependable estimate.</p> </p> Semantic filtering with humans in the loop</h3> Syntactically valid tickets were not automatically useful training examples. Test records, thanks-only replies, template answers, and solutions without technical content could all poison retrieval or supervised learning.</p> I embedded ticket text with google/embeddinggemma-300m</code>, reduced the vectors with UMAP, and grouped dense semantic patterns with HDBSCAN. The clustering did not</strong> decide what was good or bad. It changed the scale of review: support experts and I could inspect coherent groups instead of auditing 29,000 rows individually, then label clusters as useful knowledge or low-value material.</p> That review retained 79 corpus-quality clusters</strong> containing 15,404 tickets</strong>, or 52.9% of the original ticket set.</p> </p> These 79 groups are quality-control clusters. They are separate from the 281 topic-model clusters</strong> later produced by BERTopic to analyze support themes and trends.</p> Choosing the Retrieval Foundation</h2> Retrieval, duplicate detection, clustering, and text classification all depend on the embedding layer. I compared four model families with three downstream classifiers on 4,500 labeled tickets, measuring predictive quality alongside memory and encoding time.</p> </p> Model</th> Memory</th> Encode time</th> Mean downstream score</th></tr></thead> TRModel</td> ~384 MB</td> 8 s</td> 0.892</td></tr> Qwen</td> 2,274 MB</td> 45 s</td> 0.892</td></tr> EmbeddingGemma</strong></td> 578 MB</strong></td> 16 s</strong></td> 0.914</strong></td></tr> E5-Large</td> 2,136 MB</td> 24 s</td> 0.937</td></tr> </tbody></table> E5-Large produced the highest score, but EmbeddingGemma became the production workhorse: it remained within 2.3 points while using roughly one quarter of the memory and encoding 33% faster.</p> The same evaluation exposed a taxonomy problem. The source system had 194 category labels, including near-duplicates and classes with fewer than ten examples. Predicting those raw labels produced approximately 0.14 macro-F1. Support-led consolidation created seven operationally coherent groups, on which the model reached 0.46 macro-F1 and 0.67 accuracy. These are different prediction tasks, so the comparison is evidence for redesigning the taxonomy—not a claim that the model itself improved threefold.</p> The Deployed LLM Workflow</h2> flowchart LR</span></span> A["New support ticket"] --> B["Normalized ticket context"]</span></span> B --> C["EmbeddingGemma retrieval"]</span></span> C --> D["Relevant solved tickets<br/>and approved solutions"]</span></span> D --> E["Gemini answer draft"]</span></span> B --> F["Category and routing suggestions"]</span></span> E --> G["Support-expert review"]</span></span> F --> G</span></span> G -->|"approve or edit"| H["Ticket workflow"]</span></span> G -->|"reject"| I["Feedback for evaluation"]</span></span></code></pre> The deployed assistant retrieves semantically similar solved tickets and supplies their approved solutions as grounded context to Gemini. The resulting draft appears with supporting cases inside the support workflow. An expert remains responsible for the final answer, turning the LLM into an accelerator whose evidence can be inspected rather than an autonomous responder.</p> State</th> Capability</th></tr></thead> Deployed</strong></td> Hybrid retrieval, evidence-backed LLM answer drafts, expert approval workflow, and support-facing integration</td></tr> Measured research</strong></td> Corpus-quality filtering, embedding benchmarking, taxonomy redesign, classification experiments, and 281-cluster topic analysis</td></tr> Active development</strong></td> Retrieval tuning, production model APIs, assignee and resolution-time models, SLA-risk signals, anomaly detection, and richer trend reporting</td></tr> </tbody></table> Evidence and Targets</h2> Measured results and rollout targets remain deliberately separate.</p> Measured result</th> Value</th></tr></thead> Training-grade corpus</td> 15,404 tickets</td></tr> Low-value corpus identified before training</td> 47.1%</td></tr> Selected embedding model</td> EmbeddingGemma, 0.914 mean downstream score</td></tr> Consolidated-category experiment</td> 0.46 macro-F1 / 0.67 accuracy</td></tr> Topic-model granularity</td> 281 thematic clusters</td></tr> </tbody></table> Production target</th> Target value</th></tr></thead> Reduction in per-ticket handling time</td> 40%</strong></td></tr> Expert acceptance of LLM answer drafts</td> Above 80%</strong></td></tr> Human-reviewed SLA warning coverage</td> Every eligible new ticket</strong></td></tr> </tbody></table> Pilot measurement will determine whether those targets are achieved; they are not presented as current outcomes.</p> What This Demonstrates</h2> LLM systems begin with knowledge quality.</strong> Retrieval can only be as trustworthy as the solved cases behind it.</li> Human review belongs in the architecture.</strong> Support experts govern both corpus quality and every customer-facing answer.</li> Operational taxonomies matter as much as models.</strong> Redesigning an unusable label space created a prediction task the team could act on.</li> Production trade-offs beat leaderboard choices.</strong> The selected embedding model balanced quality, memory, latency, and continual ingestion.</li> Deployment is part of the research loop.</strong> Expert decisions provide the feedback needed to evaluate retrieval, prompts, routing, and future model services against real support work.</li> </ul> Electricity Consumption Forecasting for the Turkish Grid 2025-03-20T00:00:00+00:00 I led the AI and data work on this completed forecasting application, working with Universal Software’s energy team to turn live Turkish electricity-market data into reproducible forecasts, rolling backtests, and distributor-level analysis.</p> 24 h and 168 h horizons</strong> · ~1,800 scored hours per reported horizon</strong> · 21 distribution companies</strong> · Status: completed</strong></p> The central question was deliberately practical: can a zero-shot time-series foundation model compete with the official hourly load-estimation plan published by EPİAŞ, without training a custom model or engineering calendar and weather features?</em></p> What I Built</h2> Data pipeline</strong> — A client for the EPİAŞ Transparency Platform, including CAS ticket authentication and incremental updates, that retrieves hourly real-time consumption back to 2020, EPİAŞ’s published load-estimation plan, and meter data for all 21 Turkish distribution companies. The pipeline stores analysis-ready Parquet datasets and processes them with Polars.</p> Forecasting engine</strong> — TimesFM 2.5 (200M, PyTorch) running zero-shot with a 1,024-hour context window and quantile heads. Forecasts are generated in rolling 24-hour windows and support both day-ahead and week-ahead analysis.</p> Streamlit application</strong> — A single interface for live forecasts, rolling backtests, and distributor analysis:</p> Forecast:</strong> compare a generated forecast with observed demand and EPİAŞ’s published plan.</li> Backtest:</strong> evaluate 24-hour and 168-hour horizons over multiple forecast origins with MAE, RMSE, and MAPE. Every backtest uses only information that was available when its forecast would have been issued; cached artifacts make repeated analysis immediate.</li> Distributor dashboard:</strong> explore hourly meter multipliers across distributors, profile groups, and meter-reading types.</li> </ul> </p> The complete backtest application view. The metric cards and overlaid series make model-versus-baseline performance auditable down to the underlying hourly rows.</em></p> </p> The full distributor workspace. Energy specialists can move from system-level forecasting to operational comparisons across companies and customer profiles without leaving the application.</em></p> Verified Result: Competitive Until the Calendar Changes</h2> Rolling-origin backtests across April–June 2026 used multiple forecast dates at both horizons. Each forecast was evaluated against the actual consumption later observed and the EPİAŞ plan that was available at forecast time.</p> MAPE (lower is better)</th> TimesFM zero-shot</th> EPİAŞ published plan</th></tr></thead> 24 h — all reported hours</td> 3.47%</td> 3.13%</strong></td></tr> 24 h — excluding public holidays</td> 2.39%</strong></td> 2.92%</td></tr> 24 h — April 2026</td> 1.89%</strong></td> 2.89%</td></tr> 168 h — April 2026</td> 2.59%</strong></td> 2.96%</td></tr> 24 h — public holidays only</td> 12.67%</td> 4.89%</strong></td></tr> </tbody></table> </p> The failure mode is visible rather than hidden: TimesFM’s largest errors coincide with public holidays, particularly Eid al-Adha.</em></p> The result is useful precisely because it is not a universal win. On ordinary days, the zero-shot model beat the EPİAŞ baseline: 2.39% versus 2.92% MAPE</strong>. During public holidays, the ranking reversed sharply: 12.67% versus 4.89%</strong>.</p> That gap is explainable. A purely historical model can learn daily and weekly demand rhythms, but it cannot know that a national holiday will abruptly change them. At the 168-hour horizon, the effect can also persist after a holiday because the depressed demand remains inside the context window.</p> Why This Project Matters</h2> It tests a foundation model against a meaningful operational baseline rather than an artificially weak benchmark.</li> Its rolling evaluation uses multiple issue dates, two horizons, and prediction-time-available information.</li> It joins data ingestion, model inference, reproducible evaluation, and domain-facing analysis in one application.</li> Its main failure produced a concrete conclusion: calendar awareness is the highest-value next modeling improvement, not a larger univariate model.</li> </ul> Earlier experiments included ARIMA, gradient boosting, and custom PyTorch models. The completed system reflects the engineering decision that followed: use the zero-shot model where it is competitive, measure it honestly against EPİAŞ, and make the remaining limitation explicit.</p> Teus — Forecasting Flash Floods Before They Happen 2024-09-21T00:00:00+00:00 I led Teus’s R&D and analytics from raw station data through event-based evaluation and model-serving design. The analytics phase is complete; the project is now with the software team for application development. I continue to coordinate the technical handoff with the hydrologists who validate flood definitions, station behavior, rainfall weighting, and every model considered for operational use.</p> 72 h forecast horizon</strong> · 3 regions</strong> · 8 stations (5 Shown)</strong> · Hydrologist-validated flood events</strong> · Analytics complete</strong></p> </p> Selected validated event, July 4, 2023, D22A114. Discharge rose from approximately 5 m³/s to 72 m³/s in four hours. The model matched the peak magnitude closely and reached it within an hour; this event’s R² was 0.95 and flood-window error was approximately 10%.</em></p> The charts retain their original Turkish dashboard labels because the system’s users and data are Turkish: Debi</strong> = discharge, Yağış</strong> = rainfall, Taşkın</strong> = flood, Değer</strong> = value, Tarih</strong> = date.</p> </blockquote> Why Early Warning Matters</h2> Flood forecasting is not an abstract benchmark. The World Meteorological Organization reports that weather-, climate-, and water-related disasters caused more than two million deaths and US$4.3 trillion in economic losses between 1970 and 2021; countries with limited-to-moderate early-warning coverage have a disaster-mortality ratio nearly six times higher than countries with substantial coverage. WMO: Weather forecasts and early warnings</a></p> Türkiye has recent evidence of that risk. AFAD reported 82 deaths</strong> after the August 2021 floods in Bartın, Kastamonu, and Sinop. AFAD: Western Black Sea flood report</a></p> Teus is designed as decision support within that human system: a model can surface an early signal, but hydrologists decide whether its behavior is credible enough to inform an operational workflow.</p> The Modeling Problem</h2> </p> Flood events occupy roughly 1% of the studied hourly series. That rarity creates three evaluation traps:</p> A model that repeats normal river conditions can score well over the full series while missing the events that matter.</li> Flashy basins can move from low baseflow to a severe peak within hours, so discharge history alone provides little warning.</li> Random train/test splits leak event structure through time, while normalization over the full series leaks future information.</li> </ul> Ordinary MAPE is also misleading when discharge approaches zero: small absolute errors become extreme percentages and dominate the average. Teus therefore uses flood-window MAPE</strong> only during hours where discharge exceeds a station-specific, hydrologist-validated event threshold. This preserves an interpretable percentage error for the high-flow period without allowing quiet months to overwhelm the result.</p> The hydrology team defines and validates station-specific floods against official government values and domain knowledge. The evaluation does not infer operational floods from a generic statistical cutoff.</p> Evaluation That Matches Deployment</h2> I built the backtest protocol before comparing architectures:</p> Hydrologists validate flood events and station thresholds using official values.</li> Non-overlapping event windows are evaluated in time order with an expanding training window.</li> Every forecast is produced by a model that has not seen the event’s future; normalization is fitted on training rows only and boundaries are purged.</li> Models are scored with flood-window MAE and MAPE, plus a six-hour peak-window MAPE that isolates the most operationally important period.</li> </ol> Rainfall is a first-class input. Basin gauges are weighted using contributions supplied through hydrological studies, while the decoder receives a three-day external rainfall forecast produced by meteorologists</strong>. That forecast is available when Teus issues its discharge prediction—it is not subsequently observed rainfall introduced during evaluation.</p> A Controlled Architecture Comparison</h2> The reported experiment compared five strategies under the same event windows, features, and 24-hour and 72-hour horizons:</p> Model</th> Forecast strategy</th></tr></thead> Seq2Seq encoder–decoder RNN</strong></td> Encodes 168 hours of history, then generates the horizon while conditioning on the external rainfall forecast</td></tr> MIMO LSTM / MIMO MLP</td> Predicts every horizon step in one operation</td></tr> Autoregressive LSTM / MLP</td> Predicts one step, feeds it back, and repeats</td></tr> </tbody></table> The table below contains selected validated-event case studies</strong>, each compared with the strongest baseline on that same event. It illustrates behavior; it is not presented as aggregate performance across every event.</p> Station</th> Selected-event Seq2Seq flood MAPE</th> Same-event strongest baseline</th></tr></thead> D22A114</td> 8.8%</strong></td> 86.4%</td></tr> D13A074</td> 8.2%</strong></td> 38.5%</td></tr> D08A115</td> 22.5%</strong></td> 65.2%</td></tr> D22A082</td> 22.5%</strong></td> 53.7%</td></tr> D08A084</td> 34.7%</strong></td> 88.8%</td></tr> </tbody></table> The selected cases expose a consistent architectural difference. MIMO models tended to smooth sharp peaks, while autoregressive models accumulated error across long horizons. Seq2Seq could generate onset, peak, and recession while conditioning each future step on the meteorologist’s rainfall sequence.</p> Two implementation choices were especially important:</p> Scheduled sampling:</strong> the decoder gradually trains on its own outputs instead of seeing only ground-truth histories, reducing drift over 72 generated steps.</li> Forecast rainfall in the decoder:</strong> the architecture matches the operational information flow—past river and rainfall observations establish the basin state, then an available rainfall forecast informs the generated discharge path.</li> </ul> Selected 72-Hour Case</h2> </p> Selected validated event, August 2020, D22A082. After two quiet days, observed discharge rose from approximately 20 to 141 m³/s. The 72-hour forecast identified the event day and recession shape but overshot the peak at approximately 177 m³/s. That is useful evidence for hydrologist review, not proof of aggregate system accuracy.</em></p> Failure Analysis</h2> The system’s weakest selected case came from D08A084, a small, flashy basin with low baseflow and limited rainfall lead-in.</p> </p> Selected validated event, April 2021. The model identified the timing but predicted approximately 5 m³/s against an observed peak near 20 m³/s.</em></p> The failure is technically informative: relative error becomes unstable near zero, the basin has few historical events, and the available inputs do not fully represent antecedent soil moisture. These findings motivated research into pooled multi-station training and richer basin-state covariates, while the application work proceeds with the completed analytics.</p> From Analytics to a Human-Approved Product</h2> flowchart TB</span></span> RAW["Station discharge + rain gauges"] --> PREP["Continuous hourly data<br/>and basin-weighted rainfall"]</span></span> PREP --> EVENTS["Hydrologist-validated<br/>flood events"]</span></span> EVENTS --> BACKTEST["Expanding-window<br/>event backtests"]</span></span> BACKTEST --> RUNS["Reproducible run artifacts<br/>metrics · plots · models · manifests"]</span></span> RUNS --> CANDIDATE["Candidate registry<br/>station · horizon · input contract"]</span></span> CANDIDATE --> REVIEW["Hydrologist review<br/>event behavior + suitability"]</span></span> REVIEW -->|"approved"| CHAMPION["Serving champion"]</span></span> REVIEW -->|"rejected"| RUNS</span></span> CHAMPION --> API["FastAPI forecast service"]</span></span> API --> APP["Turkish operational application"]</span></span></code></pre> Every run records its dataset fingerprint, parameters, environment, predictions, metrics, plots, fitted model, and HTML report. The registry compares technically valid candidates per station, horizon, and input contract. Rain-dependent candidates are eligible only when the external rainfall forecast is supplied.</p> Technical validation does not deploy a model. It creates a candidate. Hydrologists review its event behavior and operational suitability, and only an explicitly approved checkpoint can become the serving champion. The FastAPI layer discovers approved models at runtime and keeps the last working champion available if a candidate is rejected or fails validation.</p> What This Project Demonstrates</h2> Evaluation design determines whether a rare-event model is useful.</strong> Event-based, time-ordered backtests prevent normal hours from hiding flood misses.</li> Inputs and architecture must reflect the real forecasting process.</strong> The decoder consumes a meteorologist-produced rainfall forecast that is genuinely available at inference time.</li> Selected successes and failures belong together.</strong> Both are necessary for hydrologists to judge where a model is credible.</li> Human approval is a system boundary.</strong> Model ranking supports domain experts; it does not replace their operational authority.</li> Research artifacts must survive the software handoff.</strong> Reproducible runs, explicit input contracts, and approved checkpoints allow the application team to build on completed analytics without turning a notebook result into an opaque service.</li> </ul>

Gemini 3.1 Pro</h3>
Empty</p>

HHYurdagul

MLStudio — From a 30-Company Desktop Tool to a Web ML Platform

Six Years, Thirty Companies, and One Bad Tkinter App

How Linux Changed the Way I Think

Small Example of Real Agentic Benchmarks

Fishometry — Measuring Fish Without a Reference Object

MdsAI — A Human-Reviewed LLM Platform for Support

Electricity Consumption Forecasting for the Turkish Grid

Teus — Forecasting Flash Floods Before They Happen

HHYurdagul

MLStudio — From a 30-Company Desktop Tool to a Web ML Platform

Six Years, Thirty Companies, and One Bad Tkinter App

How Linux Changed the Way I Think

Small Example of Real Agentic Benchmarks

Gemini 3.1 Pro</h3> Empty</p>

Fishometry — Measuring Fish Without a Reference Object

MdsAI — A Human-Reviewed LLM Platform for Support

Electricity Consumption Forecasting for the Turkish Grid

Teus — Forecasting Flash Floods Before They Happen

Gemini 3.1 Pro</h3>
Empty</p>