Electro Pi — AI Engineer Technical Test

Submission by Ali Elsabaa. All 4 sections implemented, tested, and documented below. Each section folder has its own README.md (setup/run instructions) and NOTES.md (write-up / trade-off discussion, matching the test's required half-page-per-section format).

Structure

electro-pi-test/
├── section1_livekit_agents/    Voice agent with tool calling
├── section2_langchain_rag/     RAG pipeline over project documentation
├── section3_quantization/      fp16 vs. 4-bit quantization benchmark
├── section4_deployment/        FastAPI + Docker service with streaming
└── .gitignore

Section 1 — LiveKit Agents

A support agent (SupportAgent) with one tool, get_order_status, tested via LiveKit's console text mode with a real LLM (Gemini) doing the tool-calling — STT/TTS mocked per the task's stated allowance. Includes the bonus provider-swap write-up.

Run: see section1_livekit_agents/README.md Evidence: demo_transcript.txt

Section 2 — LangChain RAG

Retrieval-augmented QA over 3 of my own project READMEs, with local embeddings (no API dependency), a similarity threshold that blocks out-of-scope questions before they reach the LLM, and citations to the retrieved source chunks. The write-up covers two real retrieval-quality issues found and fixed during testing (not hypothetical).

Run: see section2_langchain_rag/README.md Evidence: sample_output.txt

Section 3 — Quantization

Qwen2.5-1.5B-Instruct benchmarked at fp16 vs. bitsandbytes 4-bit NF4 on an RTX 4060: ~59% memory reduction, no meaningful speed change, no perceptible quality loss on the 5 test prompts. The write-up explains why quantization saved memory but not speed here, and when GPTQ/AWQ or GGUF would be the better production choice instead.

Run: see section3_quantization/README.md Evidence: results_summary.txt

Section 4 — Model Deployment

A FastAPI service (streaming + non-streaming endpoints) wrapping the Gemini API, containerized with Docker, load-tested at 10 concurrent requests. The write-up states upfront why I proxied to an API rather than self-hosting the Section 3 model in Docker, and covers what would change to serve 50 concurrent users in production.

Run: see section4_deployment/README.md Evidence: results_summary.txt

A note on approach

Every section prioritized a working, well-understood minimal solution over premature polish, per the test's own guidance ("partial, working solutions are valued over incomplete, over-engineered ones"). Where a design choice involved a real trade-off — mocking audio in Section 1, using local embeddings in Section 2, choosing bitsandbytes over GGUF in Section 3, proxying to an API rather than self-hosting in Section 4 — the reasoning is stated explicitly in that section's NOTES.md rather than left implicit.