CLIENT PRESENTATIONLLM API GatewayLLM CLASSIFICATIONNUMPYOLLAMAPYTHON
Accountancy
A calmer way to review financial data, surface anomalies and reconcile accounts.
Enkh-Amgalan Entwan Enkhbayar.
I am a Data Scientist and AI Engineer @
PowerServe Systems Ltd ↗ , currently based in London, UK.
I graduated from
Buckinghamshire New University ↗
with BSc(Hons) in Artificial Intelligence in June 2025.
I have so many interests, ranging from technology to sports, arts, motorcycles etc haha. Currently working on AI agents and cloud computing platforms.
Selected Work
Here are few projects I completed during my free time, at work, or while attending university.
CLIENT-FACINGRECOMMENDATION SYSTEMSGRUTENSORFLOWPROPHETPYTHON
Merchant
A recommendation system that turns purchase behaviour into more useful product discovery.
APIWEB CRAWILINGSQL DATABASEDATA PIPELINEPREDICTIONANALYSIS
Receipt
A grocery intelligence tool for seeing price changes, planning purchases and spending with intent.
RAGCLOUDFLARE WORKERS AIKNOWLEDGEBASEASTROGEMMAEMBEDDINGS
KUMO AI.exe
A small, grounded portfolio assistant with a slightly suspicious amount of personality.
SELECTED WORK
Some things I've built.
ANALYTICS / VISUALISATION
Project Five
Turning numbers into something useful
Project Five 05
IN PROGRESS
PYTHON / DATA / TOOLING
Project Six
Solving another annoying problem
Project Six 06
IN PROGRESS
AI / DATA / SOMETHING COOL
Project Seven
CooooOol things live here
Project Seven 07
IN PROGRESS
REST AREA
Meet My Portfolio AI assistant.
You can ask about me from KUMO, Play some tunes ♪ too!
KUMO.exe
Meet Kumo 雲, My old cat.
Smelled like warm popcorn. I wasn't her fan the first day, idk why. Everything changed following night when she slept on my chest whole night.
Loved her deeply.
I named her Kumo(雲) because it meant “cloud” in Japanese (also spider haha), and her soft cloudy-coloured fur made the name feel perfect.
01 / SELECTED WORK 2024 → 2025
Receipt
Turning supermarket data into smarter, budget-aware shopping.
An end-to-end platform built around hundreds of thousands of historical product records collected across five major UK supermarkets.
PYTHON SELENIUM POSTGRESQL SENTENCE TRANSFORMERS ARIMA STREAMLIT
01
The problem.
Grocery prices are constantly changing, but the tools students use to compare prices, manage a budget and plan their shopping are usually disconnected. Receipt brings those decisions together using regularly collected supermarket data.
02
What I built.
I designed and deployed an end-to-end application that collects and standardises supermarket data, compares products, tracks price movement and builds personalised shopping lists around a user's budget. The database has grown into a large historical catalogue collected across five UK supermarkets.
UNDER THE HOOD
From supermarket shelf to useful decision.
01
Retailer websites
Tesco, Sainsbury's,
Asda, Aldi and Waitrose
→
02
Automated collection
Retailer-specific
Selenium workflows
→
03
Standardisation
Names, prices, units,
discounts and categories
→
04
Data storage
Historical product data
stored in PostgreSQL
→
05
Intelligence
Semantic matching,
budgeting and forecasting
→
06
Application
Interactive Streamlit
user experience
DATA COLLECTION
Getting the data was a project of its own.
No suitable API provided consistent pricing across all five retailers, so I built a separate collection workflow for each website. The Selenium scrapers handle different page structures, JavaScript-rendered products, pagination and missing values before cleaning and standardising the results. Over time, this pipeline has built a substantial historical supermarket dataset.
SOME COOL TINGS
What Receipt actually does.
Budget-aware shopping lists
Users can type, speak or describe a meal to create a shopping list. Receipt extracts the requested items, matches them against the latest supermarket catalogue and prioritises products that fit the selected budget.
Price intelligence
Cleaned product, discount and unit-price data from five major UK supermarkets allow users to compare similar products and explore how prices change over time.
Category forecasting
Historical inflation data is transformed into time-series datasets and modelled with ARIMA to provide an exploratory view of potential short-term category-level price movement.
Nearby store finder
Users can enter a postcode or share their location to find nearby supermarkets. Geodesic distance calculations rank the results before they are displayed on an interactive Folium map.
Semantic product matching
Sentence Transformer embeddings and cosine similarity connect informal shopping requests to real product names. Cached embeddings and batched comparisons support matching across large product catalogues.
Natural language assistance
An LLM accessed through the Groq API allows users to describe a meal or request grocery suggestions naturally before converting the response into a structured shopping list.
Built as my final year Artificial Intelligence project.
Messy data in.
Smarter baskets out.
Designed, engineered and deployed from data collection to user experience.
Case study available upon request.
02 / SELECTED WORK 2025 → 2026
Accountancy
Finding the transactions worth a closer look.
As part of my work, I had the opportunity to work on a financial data review and reconciliation system in response to a client's request: help their team make sense of customer files and find the transactions that need attention.
CLIENT PRESENTATION LLM API Gateway SCIKIT-LEARN LLM CLASSIFICATION NUMPY OLLAMA PYTHON
01
What the client said.
The client said their customers often send all their files at once, leaving the team with a mix of transaction exports, bank statements and other records. It can be hard to know which files to look at first, what to look for, or whether there are any outliers in the data. They wanted help organising those files and identifying the items worth a closer look.
02
What I worked on.
My work focused on a reusable financial data pipeline that prepares files, identifies important columns, converts them into canonical schemas, runs deterministic review checks and presents the resulting signals in a Streamlit workspace. The system helps an accountant decide what deserves attention without pretending that a signal is proof of an error.
UNDER THE HOOD From raw export
From raw export
to useful review.
01Raw filesTransaction exports and bank statements from different sources
→
02PreparationCSV reading, inspection and source-column profiling
→
03IdentificationDates, amounts, descriptions and balances mapped by evidence
→
04NormalisationDifferent source layouts converted into canonical datasets
→
05Review logicAnomaly, recurring and behavioural checks with evidence
→
06Accountant UIPrioritised signals, affected rows, charts and decisions
DESIGN PRINCIPLE
A signal should explain itself.
Every review item is designed to answer three questions: what was unusual, why was it highlighted, and which rows should be checked? Findings use plain-English explanations and supporting evidence so the accountant stays in control of the final judgement.
REVIEW SIGNAL “A supplier normally receives around £2,000. This payment is £10,000.” Contextual comparison · affected rows · accountant decision
SOME USEFUL THINGS
What Accountancy actually does.
Explainable anomaly review
Highlights unusually large transactions, unusual daily activity, round numbers, repeated amounts, weak descriptions and other patterns that may deserve investigation.
Behavioural context
Compares activity within meaningful groups such as business categories or counterparties, so a payment is judged against the population where it actually belongs.
Recurring payment analysis
Learns repeated monthly or quarterly activity and surfaces missing payments, sharp amount changes and possible duplicate recurring transactions.
Transaction reconciliation
Compares transaction data with bank movements using exact, tolerant and split matching, while preserving ambiguous and unmatched cases for human review.
Evidence-first interface
The Items to review table gives every signal a priority, analysis type, plain-English explanation and affected-row count before opening the underlying evidence.
Failure-aware pipeline
Each file, review check and reconciliation service is isolated, allowing usable results to survive partial failures and making limitations visible instead of hiding them.
THE ACCOUNTANT STAYS IN CONTROL
Different does not automatically mean wrong.
The interface is deliberately built around investigation rather than automatic conclusions. An accountant can open a signal, inspect its affected transactions, compare it with normal historical activity, review charts and supporting evidence, and mark it as expected when the explanation is satisfactory.
The current synthetic demo includes clear examples of an unusually large payment, missing monthly and quarterly payments, a recurring supplier payment that increases sharply, and a possible duplicate payment.
Built as a foundation for a wider accounting SaaS platform and built Streamlit front end for a client presentation.
Messy records in.
Clearer reviews out.
Designed around reusable data contracts, explainable checks and an accountant-led review workflow.
03 / SELECTED WORK 2026
ONLINE
KUMO AI.exe
A suspiciously well-informed little AI living inside my portfolio.
Kumo is a retrieval-augmented portfolio assistant built to answer questions about me, my work, projects, education, skills and interests without pretending to know things that are not actually in the knowledge base.
RAG CLOUDFLARE WORKERS AI VECTORIZE ASTRO TYPESCRIPT GEMMA EMBEDDINGS
01
Why I built it.
I wanted the portfolio to do more than just show static text about me. The idea was to let visitors ask questions naturally and explore the person behind the projects, while keeping the answers grounded in information I actually provided.
02
What I wanted to learn.
Kumo became a practical way for me to learn how retrieval-augmented generation works end to end, including knowledge chunking, embeddings, vector search, retrieval quality, grounded generation and connecting an AI backend to a real frontend.
UNDER THE HOOD
Question in.
Question in.
Relevant context out.
01 Visitor question
A natural-language question about me or my work.
→
02 Normalise
Aliases like Entwan and Enkh are mapped consistently for retrieval.
→
03 Embed
The question is converted into a vector using Workers AI.
→
04 Retrieve
Vectorize finds the most relevant chunks from the knowledge base.
→
05 Generate
Kumo answers using only the retrieved evidence.
THE PART I CARE ABOUT
It should know when it does not know.
Grounded answers
Kumo is instructed to answer from retrieved evidence rather than filling gaps with invented details.
Dynamic knowledge
Projects, skills and interests live in a separate knowledge base, so new topics can be added without rewriting Kumo's whole prompt.
Unknown-answer handling
Similarity alone is not treated as proof. If retrieved chunks do not actually answer the question, Kumo simply says it does not know.
A bit of personality
The assistant is designed to feel familiar and slightly playful, without inventing fake memories or turning into a generic chatbot.
Ask the portfolio
instead of reading it.
Kumo is still evolving as I add more projects, topics and knowledge.
04 / SELECTED WORK CLIENT-FACING PROJECT
Merchant
Recommendation System
The right product,
for the right customer.
A client-facing recommendation and demand intelligence system built for a plumbing merchant. The project uses historical customer and sales behaviour to personalise product discovery, suggest useful basket additions and help the business understand future product demand.
CLIENT-FACING RECOMMENDATION SYSTEMS GRU TENSORFLOW PROPHET STREAMLIT PANDAS PYTHON
01
What the client needed.
The merchant has a large catalogue of plumbing, heating, ventilation, fittings, tools and related products. The challenge was helping customers find products that are actually relevant to them, while also identifying complementary items that naturally belong together.
The client also wanted to make better use of historical sales data behind the scenes, particularly for understanding product demand and supporting stock planning.
02
What I worked on.
I designed a recommendation framework that changes behaviour depending on what the system knows about the customer.
New visitors receive sensible popularity-based recommendations, returning customers receive personalised predictions from their purchase history, and basket activity triggers related-product recommendations based on historical buying behaviour.
I also developed a product-level demand forecasting pipeline and built the recommendation scenarios into an interactive Streamlit application for the client.
UNDER THE HOOD
One dataset.
One dataset.
Several ways to help.
01 Sales history
Customer, product, quantity, price, discount and transaction history
→
02 Preparation
Invalid records removed and customer purchase histories prepared
→
03 Customer context
New visitor, returning customer, basket activity or combined context
→
04 Recommendation
Popularity, GRU sequence modelling and item co-occurrence
→
05 Demand intelligence
Monthly product-level forecasting using sales and behavioural features
→
06 Client demo
Interactive Streamlit interface for testing realistic customer scenarios
DESIGN PRINCIPLE
Context decides
Context decides
the model.
I did not try to force every customer through the same model. A completely new visitor does not have enough information for meaningful personalisation, while a returning customer or an active basket provides much stronger behavioural signals.
The system chooses a recommendation strategy according to what information is actually available.
EXAMPLE FLOW
No history?
Start with what works. New customer → popular products
Purchase history → GRU recommendations
Basket activity → frequently bought together
Start with what works. New customer → popular products
Purchase history → GRU recommendations
Basket activity → frequently bought together
RECOMMENDATION STRATEGY
Different customer.
Different customer.
Different signal.
Start with popularity.
With no customer history or basket information, recommendations fall back to products that consistently appear in historical purchases.
GLOBAL POPULARITY
Learn what comes next.
Customer purchases are converted into ordered product sequences. A GRU model learns repetition, transitions and purchasing patterns to predict likely future products.
GRU SEQUENTIAL MODEL
Look at what belongs together.
Historical orders are analysed to find products that commonly appear together, allowing the system to suggest useful additions while the customer is actively shopping.
ITEM CO-OCCURRENCE
MORE THAN ONE MODEL
What the system actually does.
Cold-start recommendations
Uses historical product popularity when there is no customer history available, ensuring new visitors still receive useful recommendations.
Sequential personalisation
A GRU-based recommender learns ordered customer purchase behaviour, repeat buying patterns and product transitions to generate personalised Top-N predictions.
Frequently bought together
Item co-occurrence analysis identifies products that historically belong together, supporting basket expansion and practical cross-selling.
Commercial recommendations
Recommendation logic can also consider discounted products and business-priority items rather than relying entirely on machine learning output.
Demand forecasting
Historical sales are converted into monthly product-level time series and forecast using Prophet with price, discount, time and regional holiday features.
Parallel forecasting
A custom Python pipeline processes and forecasts many products concurrently using ThreadPoolExecutor, with tqdm providing live progress throughout longer model runs.
FROM RECOMMENDATIONS TO STOCK PLANNING
What might sell next,
What might sell next,
and how much?
The same sales history used to understand customer behaviour is also transformed into monthly product-level time series for demand forecasting.
The pipeline incorporates quantities, pricing, discounts, seasonality and regional holiday effects before fitting product-level Prophet models.
MAPE Percentage error
SMAPE Symmetric percentage error
WAPE Volume-weighted error
Forecasting experiments were designed to compare product-level model behaviour rather than claim a single universal accuracy figure across the entire catalogue.
ITERATION
It grew past
It grew past
one recommender.
RECOMMENDATION
The first idea developed into a scenario-based recommendation architecture with separate strategies for anonymous visitors, returning customers and active baskets.
I later added discounted-product recommendations, business-priority ranking and a Streamlit interface so the client could interact with the different behaviours directly.
FORECASTING
The demand pipeline evolved from basic product forecasting into a configurable monthly processing system with external regressors, holiday features, lag experiments and per-product validation.
Performance became its own engineering problem, leading to experiments with Dask, process-based parallelism, thread-based execution, regressor pruning and live progress monitoring.
Client-facing recommendation system developed for a plumbing merchant.
Help customers choose.
Help the merchant prepare.
Recommendation systems, customer behaviour modelling and demand forecasting built around the same real-world sales problem.
KUMO.exe ONLINE
KUMO
Hello, I'm Entwan's assistant, ask me about him.
SIGN THE GUESTBOOK
Leave a little note.
No notes yet. Be the first.
Welcome back, boss.
THE WALL
