| | --- |
| | title: RAG Observability Platform |
| | emoji: 🚀 |
| | colorFrom: blue |
| | colorTo: indigo |
| | sdk: docker |
| | pinned: false |
| | app_port: 7860 |
| | --- |
| | |
| | # RAG Observability Platform 🚀 |
| |
|
| | # RAG Observability Platform - Project Summary |
| |
|
| | ## Project Overview |
| |
|
| | The **RAG Observability Platform** is a production-grade Retrieval-Augmented Generation (RAG) system that demonstrates advanced MLOps practices and hybrid cloud-local deployment strategies. It combines cutting-edge ML inference optimization (Apple Silicon GPU) with MLOps observability frameworks for enterprise-ready applications. |
| |
|
| | --- |
| |
|
| | ## What This Project Does |
| |
|
| | ### Core Functionality |
| | 1. **Local RAG Pipeline (Mac M4)** |
| | - Ingests unstructured text documents |
| | - Chunks documents using recursive text splitting |
| | - Generates embeddings via sentence-transformers (optimized for Apple Silicon via MPS acceleration) |
| | - Stores embeddings in ChromaDB (local vector database) |
| | - Retrieves relevant context and generates answers using Llama 3.2 3B model via MLX |
| |
|
| | 2. **Cloud Deployment (Hugging Face Spaces)** |
| | - Docker containerization for reproducible deployment |
| | - Automatic fallback to CPU-based inference when MLX unavailable |
| | - Streamlit web UI for interactive chat with documents |
| | - Graceful degradation: maintains functionality across platforms |
| |
|
| | 3. **Experiment Tracking (Dagshub + MLflow)** |
| | - Logs all ingestion runs with parameters and metrics |
| | - Centralized experiment monitoring from local machine |
| | - Version control for code and data via Git + DVC |
| | - Remote MLflow server for team collaboration |
| |
|
| | ### Technical Highlights |
| | - **Cross-Platform Optimization**: Native M4 GPU (via MLX) for local development; CPU fallback for cloud |
| | - **Infrastructure as Code**: Docker + UV for reproducible environments |
| | - **Modern Python Stack**: LangChain (LCEL), Pydantic, asyncio-ready |
| | - **MLOps Best Practices**: Experiment tracking, dependency management, secrets handling |
| | --- |
| |
|
| | ## Key Highlight |
| |
|
| | 1. **GPU Optimization**: Understand when to use specialized tools (MLX for Apple Silicon) vs. standard libraries (PyTorch) |
| | 2. **Cross-Platform Development**: Device abstraction, graceful fallbacks, testing on multiple architectures |
| | 3. **Dependency Management**: Using UV for faster resolution, managing optional dependencies (local vs. cloud groups) |
| | 4. **MLOps Practices**: Experiment tracking, versioning data + code, secrets management |
| | 5. **Production Deployment**: Docker best practices, environment variable injection, port mapping |
| | 6. **Modern Python**: Type hints, LangChain LCEL (functional composition), error handling |
| | 7. **Troubleshooting**: Resolved Python version mismatches, binary file handling in Git, device compatibility issues |
| |
|
| | --- |
| |
|
| | ## Why This Project Stands Out |
| |
|
| | - **Full Stack**: From local GPU optimization to cloud deployment |
| | - **Senior-Level Considerations**: |
| | - Device compatibility across platforms |
| | - Graceful degradation (MLX → Transformers fallback) |
| | - Secrets management without pushing `.env` |
| | - Experiment observability |
| | - **Modern Tooling**: UV (faster than pip), MLX (Apple Silicon optimization), LangChain LCEL (declarative chains) |
| | - **Problem Solving**: Resolved real-world issues (ONNX version compatibility, Docker base image mismatch, GPU device detection) |
| |
|
| | --- |
| |
|
| | ## GitHub/Portfolio Presentation |
| |
|
| | **Repository Structure** (visible in your GitHub): |
| | ``` |
| | rag-observability-platform/ |
| | ├── src/ |
| | │ ├── ingestion/ (document loading, chunking, embedding) |
| | │ ├── retrieval/ (RAG chain with LCEL) |
| | │ └── generation/ (MLX wrapper, device handling) |
| | ├── app/frontend/ (Streamlit UI) |
| | ├── Dockerfile (Cloud deployment) |
| | ├── pyproject.toml (UV dependency management) |
| | └── README.md (project documentation) |
| | ``` |
| |
|
| | **Git History** (visible in commits): |
| | - Clean, semantic commits showing progression |
| | - Branching strategy: `master` → `mvp` → `frontend`/`backend` |
| | - Demonstrates collaborative workflow understanding |
| |
|
| | --- |
| |
|
| | 1. **"Why MLX instead of PyTorch?"** |
| | - MLX is optimized for Apple Silicon; PyTorch CPU mode is 10x slower on M4 |
| |
|
| | 2. **"How do you handle the MLX import error in Docker?"** |
| | - Try-except with fallback to transformers; dynamic device selection |
| |
|
| | 3. **"Why use Dagshub for this portfolio project?"** |
| | - Demonstrates understanding of MLOps practices; shows ability to connect local experiments to remote tracking |
| |
|
| | 4. **"What would you do at scale?"** |
| | - Move to managed inference (HF Inference API), DVC for larger datasets, Kubernetes for orchestration |
| |
|
| | --- |
| |
|
| |
|
