I got into AI in 2023, right when it became the word everyone used and for a while, just using GenAI felt like being an AI engineer. It wasn't, until I went back to fundamentals, decision trees to XGBoost in college labs, Kaggle nights... Then NLP, chatbots and my first hackathon wins, all while CS core kept me grounded. Working on real ground problems and publishing research taught me building isn't enough, explaining it clearly matters just as much.
That mix of curiosity and discipline is why I ended up, moving from prototypes to real agentic systems with LangChain and RAG, and now voice AI with Pipecat and LiveKit. I'm an AI engineer because I stayed with the unglamorous parts long enough to actually lead in them, not because AI is trending.
flowchart LR
A[Obvious approach] -->|"LLM decides everything"| B[Fails silently]
A -.->|instead| C[What I actually build]
C --> D[Deterministic logic where possible]
C --> E[Retrieval where knowledge is needed]
C --> F[LLM restricted to explanation]
D & E & F --> G[System you can audit]
style B fill:#3d1a1a,stroke:#a83232,color:#e0b3b3
style G fill:#1a3d24,stroke:#32a852,color:#b3e0c1
Not every problem needs an LLM to solve it. Some just need an engineer who can look at the problem, reason through it, and point to the simpler solution — logic, retrieval, a rule that the AI wouldn't suggest on its own. Below is where that judgment shows up.
|
The obvious build: dump regulations into a vector DB, wrap an LLM around it. I didn't because in RBI/SEBI/GST compliance, a hallucination that sounds well-sourced is more dangerous than an obvious error. What I built instead: a hybrid system where the LLM never decides — it only explains what a rule engine already decided. |
flowchart TD
Q[User query] --> R{Rule engine:<br>deterministic?}
R -->|Yes| RE[Apply known rule]
R -->|No| RAG[Retrieve via ChromaDB]
RE --> EXP[LLM: explain only]
RAG --> EXP
EXP --> OUT[Answer + audit log]
OUT --> SQL[(Immutable<br>SQLite trail)]
|
Why this took longer to build — and why that was the point
Encoding known regulations as deterministic rules is slower than letting an LLM "figure it out." But an MSME acting on bad compliance advice faces real fines. The rule engine handles what's actually deterministic across RBI, SEBI, GST, MCA, and Labour frameworks; RAG handles document lookup where rules don't cover it; the LLM's only job is turning a decision into plain English. Every decision is logged to an immutable audit trail — because "trust me" isn't an audit strategy.
FastAPI ChromaDB SQLite · → github.com/Vedika-Sd/ComplianceOS-v1
Published · ICETIS 2026
Most RAG pipelines answer even when they shouldn't. I spent most of the engineering effort on the unglamorous part: making the system refuse correctly.
| Metric | Before | After |
|---|---|---|
| Hallucination rate | 20% | 8% |
| Out-of-scope rejection | 5% | 90% |
Why "rejection rate" is the metric that mattered
Anyone can tune a RAG pipeline to answer more confidently. Getting it to correctly say "this is outside what I know" 18× more often — without becoming useless-cautious on in-scope questions — is the harder, less celebrated problem. It's the one that matters if the system ever touches a real financial decision.
Standard forecasting assumes clean seasonality. Real dairy sales in Maharashtra spike around 46 regional festivals no off-the-shelf model has heard of, and no single algorithm wins across every product type.
flowchart LR
S[35 SKUs, 5yrs daily sales] --> Router{4-segment<br>product router}
Router --> P[Prophet]
Router --> SX[SARIMAX]
Router --> XG[XGBoost]
Router --> CR[Croston's<br>intermittent demand]
P & SX & XG & CR --> OUT[7.0% volume-weighted WAPE]
Hand-built the 46-festival demand calendar, no library had one. Served via FastAPI with a model registry.
Python Prophet SARIMAX XGBoost · → github.com/Vedika-Sd/Demand-Forecasting
Most churn projects stop at reporting ROC-AUC. This one ships an explanation with every prediction — SHAP integrated directly into the API response, so a business user sees why a customer is flagged, not just a probability.
| ROC-AUC | 0.79 |
| F1-optimized threshold | 0.61 |
| Training data | 50K real banking records |
| Response time | sub-second, containerized, live on Render |
Actually try it:
curl -X POST https://[live-render-endpoint]/predict \
-H "Content-Type: application/json" \
-d '{"customer_data": "..."}'LightGBM SHAP FastAPI Docker · → github.com/Vedika-Sd/Indian-Bank-Churn-Prediction
| Your problem involves... | Look at |
|---|---|
| Regulated / high-stakes domains where wrong answers cost money | ComplianceOS, TA-RAG |
| Forecasting with messy, non-standard seasonality | Demand Forecasting |
| Production ML that has to explain itself | Churn Prediction |
| Multi-agent systems under time pressure | StratArena — built in 36hrs, top 800 of 31,000+ teams |
Proof, for the skeptical (achievements & publications)
- 2nd place, 6,000+ teams — IndiaAI × IBM GenAI Hackathon — StartupSarthi, agentic compliance assistant
- Top 800 of 31,000+ teams — Meta × PyTorch OpenEnv Hackathon — StratArena, multi-agent RL with Theory-of-Mind opponent modeling, built in 36 hours
- Published, ICETIS 2026 — TA-RAG, hallucination reduction in regulatory RAG
- Published, IRJAEH 2025 — ML-based crop recommendation framework for Indian agriculture (DOI 10.47392/IRJAEH.2025.0472)