Engineer
Senior ML Engineer | GenAI + RAG Systems | Fine-tuning | MLOps | Conversational & Document AI Building reliable, real-time AI systems across high-impact domains — from Conversational AI and Document Intelligence to Healthcare, Retail, and Compliance. At 7-Eleven, I lead GenAI initiatives involving LLM fine-tuning (Mistral, QLoRA, Unsloth), hybrid RAG pipelines, and multimodal agent-based bots. Domains I specialize in: Conversational AI (Teams + Claude bots, product QA agents) Document AI (OCR + RAG, contract Q&A, layout parsing) Retail & CPG (vendor mapping, shelf audits, promotion lift) Healthcare AI (clinical retrieval, Mayo Clinic work) MLOps & Infra (Databricks, MLflow, vector DBs, CI/CD) Multimodal Vision+LLM (part lookup from images) I work at the intersection of LLM performance, retrieval relevance, and scalable deployment — making AI not just smart, but production-ready. Let’s connect if you’re exploring RAG architectures, chatbot infra, or fine-tuning strategy!
Markdown supported · ⌘↵ to post
Executable specs only help when the verifier runs in CI. I treat the spec as a failing test until the automation proves the same path twice.
Mihai_LeanZero
The per-target checkpoint idea is the part that makes this different from a shared summary, since Claude and Codex genuinely need different deltas depending on when each last checked in. What I don't see covered is concurrent writes to the same decision. If Claude and Codex are both active on the same task from different checkpoints and each supersedes the same decision differently before either syncs, something has to arbitrate which supersession wins, or surface the conflict instead of silently picking one. Git has merge semantics for exactly this. Does the current alpha have anything equivalent, or does it assume writes are effectively serialized through the user's approval flow?