log/ianHyeonseok JeongEmail

Learning Lab / Machine Learning · NLP · API Productization

IntentGuard ML Service

I am implementing a full ML service that classifies customer requests, rejects unsupported requests, and leaves enough evidence to reproduce and improve the result.

  • Intent Classification
  • Out-of-Scope Detection
  • FastAPI
  • Reproducibility
Role
ML service learner and implementer
Period
2026 · In progress
Type
Independent AI/ML learning lab
Status
End-to-end practice in progress

Proof at a Glance

Evidence
  • The project scope includes data verification, a baseline, a PyTorch training loop, OOS evaluation, FastAPI, tests, Docker, DVC, and CI.
  • A complete Korean manual and tested reference implementation are ready for my personal execution.
  • I will publish personal metrics only after I run the full pipeline and preserve the evidence myself.
Public and Validation Boundary
  • The reference implementation is not presented as my independent completed work.
  • No performance number on this page is claimed as my personal result yet.
  • The project becomes a completed portfolio case only after clean-environment reproduction.

Work flow

Structure and Flow

  1. 01Verify data

    Download CLINC150, check the SHA-256 value, inspect schema, duplicates, and split leakage.

  2. 02Build a baseline

    Train TF-IDF and Logistic Regression before adding a more complex model.

  3. 03Train and evaluate

    Write a PyTorch loop, compare models, and keep the final test set untouched until evaluation.

  4. 04Reject unknown requests

    Choose the OOS threshold with validation data and measure both in-scope quality and rejection behavior.

  5. 05Serve and reproduce

    Expose prediction, batch, feedback, health, and metrics APIs, then verify them with tests, Docker, DVC, and CI.

The problem

An intent classifier should not force every request into a known category. In a real service, users ask things the system does not support. IntentGuard must classify supported requests and return oos when confidence is too low.

That makes this more than a notebook exercise. The project needs data checks, a simple baseline, a trainable model, honest evaluation, an API, tests, and a reproducible environment.

Why I chose this project

My earlier work connected camera data, model outputs, APIs, and visible results. IntentGuard lets me study the ML part more deeply while keeping the same practical question: how does a model result become a service people can trust?

The implementation path

I am working through the project in this order:

  1. Download the official data and verify its checksum.
  2. Audit labels, splits, duplicates, and possible leakage.
  3. Build a TF-IDF and Logistic Regression baseline.
  4. Write and train a PyTorch classifier.
  5. Select the OOS threshold with validation data only.
  6. Evaluate classification, rejection, calibration, and latency on held-out data.
  7. Expose prediction, batch, feedback, health, and metrics endpoints with FastAPI.
  8. Reproduce the project with tests, DVC, Docker, CI, and a clean setup guide.

What I will not hide

The final review will include weak results as well as strong ones. If OOS recall is low or confidence is poorly calibrated, I will record that as the next engineering problem instead of selecting only a favorable metric.

Current completion boundary

The manual and reference code are ready, but my personal execution evidence is still being created. I will promote this page from a learning lab to a completed case study only after I can reproduce the data audit, training, evaluation, API, tests, and clean-environment setup myself.

What completion will prove

The finished project should show that I can move from a public dataset to a tested API service, explain why each evaluation rule exists, and reproduce the result without hidden local steps. That is the standard I want for future AI and ML work.