← Work experience Applied AI

Company
Astrion
Role
ML / AI Engineer
When
2025 — Now
Where
Huntsville, AL (remote)

Mission operations & engineering intelligence

Turning maintenance records, telemetry and years of engineering documents into something mission teams can act on: predictive models for equipment events, retrieval that understands the question, and Graph RAG for the questions a vector search alone can't answer.

  • Python
  • PySpark
  • XGBoost
  • LightGBM
  • BERT
  • FAISS
  • OpenSearch
  • pgvector
  • Neo4j
  • GPT-4
  • LangChain
  • LangGraph
  • LangSmith
  • FastAPI
  • AWS
  • MLflow
Graph RAG
Retrieval
FastAPI
Served via
ML / AI Engineer
Role
XGBoost · LightGBM · Random Forest
Models

Architecture

  1. 01Sourcesevents, maintenance, telemetry, docs
  2. 02Spark prepPySpark + SQL, dedupe, fixes
  3. 03Predictive modelsXGBoost · LightGBM
  4. 04RetrievalFAISS · OpenSearch · pgvector
  5. 05Graph RAGNeo4j + GPT-4 / LangGraph
  6. 06ServicesFastAPI · Docker · MLflow

The problem

Mission and engineering teams sit on a lot of data that never makes it into a decision: equipment events, maintenance comments, telemetry, incident write-ups and years of technical documentation. Routine reporting shows what happened. The patterns behind it, and the document that explains a recurring failure, stay buried.

Predicting equipment events

I built predictive workflows around equipment events and operating conditions with Scikit-learn, XGBoost, LightGBM and Random Forest. Most of the work was in the features: turning historical event and maintenance records into signals a model can use. Models were tuned with cross-validation, Grid and Randomized Search and Optuna, and compared against the engineering requirements, not a single metric.

Source data came from structured databases and large operational datasets, joined with Apache Spark, PySpark and SQL in repeatable preparation routines that handle inconsistent values, missing records, duplicate events and source structures that change.

Making the documents searchable

Engineering notes, incident descriptions and maintenance comments became usable signals with Hugging Face Transformers, BERT, spaCy and Sentence Transformers. On top of that I built document retrieval with RAG, FAISS, OpenSearch and pgvector, so people find the right technical information by what they mean rather than by exact keywords.

Graph RAG and GenAI workflows

Some questions are about relationships: which equipment, which events, which documents. Connecting them in Neo4j and using Graph RAG gives those questions context a vector-only search misses. GenAI workflows were prototyped with OpenAI GPT-4, LangChain and LangGraph, chaining retrieval, context preparation and generation while keeping answers tied to approved technical content. LangSmith traced prompts and retrieval so unexpected answers could be investigated.

Trust and delivery

  • Explainability: SHAP and LIME show which operational and engineering variables drive each prediction.
  • Services: selected ML and GenAI components ship as lightweight FastAPI services in Docker, consumed by internal engineering applications.
  • Cloud: AWS S3, SageMaker, EC2, Glue and Redshift, moving models from local experiments to repeatable cloud workflows.
  • Reproducibility: MLflow records parameters, metrics, artifacts and model versions; Git, GitHub Actions and CI/CD keep experimental work apart from releases.
  • Communication: Tableau, Matplotlib and Plotly views of operational trends, recurring events and model behaviour for engineering stakeholders.

Contact

Want the longer version?

Happy to walk through any of this in detail — the parts that broke are usually the interesting bit.