Triager+: From Concept to Execution
Triager+ began as a challenge — to combine machine learning with a usable, focused web interface for classifying help desk tickets. But it evolved into something more: an exercise in product minimalism, memory-aware architecture, and end-to-end delivery from backend to UI. This is the story of its construction.
What Came Before?
Before Triager+, there were experiments with CSVs, local Jupyter notebooks, and isolated model training sessions. Ticket classification lived as a script, not a product. No UI, no backend — just direct calls to predict functions for hardcoded strings. The challenge wasn’t just in modeling — it was in integrating those models into a user-facing experience.
What Is Triager+?
Triager+ is a web-based tool that classifies help desk ticket descriptions into categories and priorities. At its core, it’s a text classifier powered by both a lightweight Naive Bayes model and an optional (currently disabled) DistilBERT deep learning model. The goal was to make something useful, lightweight, and easily hostable — a proof of concept for real-world applications, built cleanly and without fluff.
Why Build It?
This project emerged from a desire to make something practical, fast, and visually simple. Unlike sprawling web apps, Triager+ was an exercise in clarity: take in a sentence or two, and give the user a high-confidence classification. But it was also strategic — a demonstration of the ability to integrate modern AI with scalable backend/frontend deployment. In a world overrun by toy projects and API demos, Triager+ aimed to deliver a product with edges — lightweight, yet real.
Why These Models?
Naive Bayes was chosen for its speed, simplicity, and low memory requirements. It's well-suited for baseline classification, especially when combined with TF-IDF vectorization. DistilBERT was added as an advanced option — a distilled transformer model capable of deeper semantic understanding. While more powerful, DistilBERT's memory usage was too high for the free-tier deployment, leading to its graceful exclusion with a fallback to Naive Bayes.
Architecture Overview
The architecture breaks down into three primary components:
- Backend: A FastAPI app hosted on Render that routes prediction requests, handles preprocessing, and returns model outputs.
- Model Layer: A Naive Bayes classifier trained on labeled help desk data using TF-IDF vectorization. DistilBERT is implemented but temporarily disabled due to memory limits.
- Frontend: A pure HTML/CSS/JavaScript interface served via GitHub Pages, enabling instant user interaction with no external libraries.
Training the Models
The initial training dataset consisted of a structured CSV of ticket entries labeled with category and priority. After cleansing and balancing the data, a TF-IDF pipeline was applied. The Naive Bayes model was trained separately for category and priority, then serialized using joblib. While a fine-tuned DistilBERT model performed better, it exceeded RAM limits on the free Render plan and was therefore deferred to a premium deployment tier.
Handling Constraints
Developing Triager+ involved navigating several very real limitations:
- Cross-Origin Resource Sharing (CORS): Required custom middleware to allow calls from the frontend’s domain.
- Memory Constraints: Forced the Naive Bayes model to be the default with DistilBERT conditionally disabled.
- Static Hosting: The frontend is purely static, so prediction requests needed to interface cleanly via CORS-aware JavaScript and JSON payloads.
Designing the UI
Instead of bloated frontend frameworks, a clean hand-coded interface was developed. The layout is mobile responsive, the color palette stays out of the way, and each control (textarea, dropdown, buttons) is styled for ease of use. The interface reveals prediction results on demand and includes a “Clear” button for reset. Google Analytics was added minimally for basic pageview insights.
Lessons Learned
- Minimalist AI tools can deliver high impact if thoughtfully scoped.
- Deployment friction is part of product design; testing CORS locally is not enough.
- A project’s boundaries are often where its identity is clearest — Triager+ knows what it is, and that’s its strength.
What’s Next?
Triager+ now exists as a finished demonstration. The next project — ShapeSound — will explore new dimensions: visual-audio translation, generative design, and user-guided creative tools. But Triager+ was the prototype of purpose. Fast, smart, and focused.