ML/AI Engineer — London, UK

Feruza Kachkinbayeva

I build AI systems
that turn complex data
into decisions.

scroll

Ask me anything

Grounded in real work. Speaks in my voice if you want.

feruza-agent@london:~
◆
$

// projects

Three systems. Two in production. One shipping.

London Café Site Intelligence

SLA Master's Award 2024

4,835 LSOAs. AHP-weighted opportunity scores. Built for my MSc thesis.

loading map_

AHP weighting synthesises 12 site-suitability factors — footfall potential, competition density, transport access, and demographics — into a single opportunity score per LSOA. Consistency ratio: 0.06.

Thesis PDF
University of Greenwich · MSc Thesis 2024
Distinction

Location Intelligence — Café Site Selection

SLA Masters Award 2024 · 2nd Place

Problem

74% of new cafés in the UK fail within five years. Site selection costs £50,000+ to get wrong and most decisions rely on gut instinct and borough-level demographics that miss how dramatically conditions vary within short distances across London.

What it does

A three-task data-driven framework across 4,835 London LSOAs at granular sub-borough level. Task one: predict café success potential by area. Task two: predict commercial rent prices. Task three: find the intersection where success potential is high and rent is below market rate — that is where you open.

Key finding

Public transport accessibility dominated the model (16.92% AHP weight), above median house price, demographics, or foot traffic proxies. The more commercially valuable output was identifying emerging neighbourhoods with medium-high success scores not visible in traditional market research — areas that conventional consultancy would miss entirely.

Scale

16,361-word dissertation covering multi-source data integration, AHP weighting methodology, geospatial ML modelling, and rent prediction — then synthesised into an interactive map deployed as part of this portfolio.

PythonGeoPandasscikit-learnAHPFoliumPostgreSQLGeospatial ML
University of Greenwich
Feature-complete

HESA Stat Returns Hub

CFO Staff Recognition Award 2025 · Efficiency and Innovation

Problem

HESA statutory returns are a regulated workflow with hard deadlines. Missed sign-off gets reported to the Office for Students. The existing process ran on Banner extracts, Python and Alteryx scripts, Excel trackers, email chains. Hundreds of quality rules per cycle, no central view, no audit trail.

What it does

Governance and submission pipeline in one tool. Role-based access, invitations, append-only audit log, multi-institution dashboard with risk scoring. The pipeline handles XML upload, lxml-based XSD validation, OVT quality report ingestion, per-rule triage and team assignment, failure drill-down, and Core File generation from the 28 TSV outputs HESA returns after sign-off.

In progress

LLM module on Azure OpenAI with RAG over 200+ pages of regulatory guidance. Natural-language rule queries, tolerance-request drafting, schema-change summaries. Next phase: an agent layer that updates pipeline scripts behind a review gate, generates visualisations on demand, and drives the triage loop from intent.

DjangoReactTypeScriptPostgreSQLlxmlAzure OpenAIRAG
31 days · 165 commits
GitHub

LifeOS

What it is

A mobile-first personal operating system. Today view with energy tracking, calendar, goals, check-ins, analytics, and a conversational assistant with persistent memory. Full-stack, deployed, in daily use since Day 31.

Architecture decision

The memory system went through three versions in three days. Store everything. Inject everything. Score and select. The first two were thorough. Only the third was useful. The problem was never storage — it was knowing what matters right now. The assistant uses selective injection: memories are scored against the current context and only passed to the model above a relevance threshold.

What I learned

Working and right are different things. The lesson wasn't to slow down. It was to know what I was optimising for before I started.

FastAPIReact NativePostgreSQLOpenAIRailway

What I'm working through

A commit log for thinking. Not polished — that's the point.

thinking.log0 entries
loading_

// about

Working with me

How I think

Before I think about what a system can do, I try to settle what it shouldn't get wrong. Most failures I've seen aren't a model problem. Nobody decided the constraint first. Once you've got that, the architecture mostly writes itself.

What I'm building toward

Getting a model to perform well is one problem. Making that output repeatable and reliable enough for a team to build on is a different one. That second problem is what I want to work on.

What kind of work I want

Work that gets deployed and has something real attached to it. Not a notebook that runs once. Actual decisions changing because the system exists. The harder version of that is figuring out how to make it repeatable after it works the first time.