S
fr

Hi, I am

Sadok Aziz Ben Younes

AI & LLM Engineer

Building intelligent systems, AI agents — and the tests that prove they work.

  • AI / LLM systems
  • Multi-agent architectures
  • RAG systems
  • Test strategy & automation
  • MLOps / LLMOps
  • Backend engineering
View ProjectsDownload CV
Sadok Aziz Ben Younes

About

AI systems are only finished when something proves they work.

I graduated from ENSI in September 2026 with an engineering degree in computer science. Across three internships I built the same thing in different shapes: an AI system that has to survive contact with real users. A voice assistant answering in real time. A vision pipeline reading a live traffic feed. Agent tooling that lets a model act on a calendar and an inbox.

The interesting problems were rarely in the model. They were in the orchestration, the failure modes, the cost of a slow response, and knowing whether a new version was actually better than the one it replaced. That is the work I want more of.

How the layers stack

  1. AI Engineering

    Turning a capability into a component with a contract.

  2. LLMs

    Prompting, fine-tuning and quantisation, chosen by constraint.

  3. Agents

    Graphs of specialised steps instead of one prompt doing everything.

  4. Data

    Retrieval, feature pipelines and versioning that make results reproducible.

  5. Production Systems

    Latency budgets, observability, CI, and a deliberate path to release.

Experience

Where the systems were built.

Three internships, each one further up the stack from model to product.

  1. Key achievements

    • Built Voice Vibe, a real-time voice assistant plugin. A single prompt handling a whole spoken conversation is slow and impossible to debug, so I split it into six specialised LangGraph agents composed as a graph, wired over a WebSocket STT/TTS pipeline, with every stage observable so a bad turn traces to one node.
    • Measured end-to-end latency at roughly 975–1020 ms p50, voice in to voice out, with all six agents running on every turn.
    • Benchmarked that against five production voice platforms to locate the real bottlenecks rather than the assumed ones.
    • Designed an end-to-end MLOps pipeline (CRISP-DM) for a suggestion-acceptance recommender, with leak-free feature engineering and calibrated LightGBM and logistic regression models tracked in MLflow and DVC.
    • Shipped a deterministic promotion gate — shadow, then gate, then promote — so no model version reached production unmeasured.
    • Built a two-level test strategy: 262 tests — unit tests over the critical deterministic logic, functional tests over REST and WebSocket through a test client — running in GitHub Actions CI on every push and pull request, reaching 63% line and 57% branch coverage.
    • Added a Postman layer of REST collections alongside the pytest suite, and ran and maintained both the manual and automated test campaigns each sprint, analysing results and tracking anomalies through to closure.
    • Replaced the external STT/TTS services with fakes so the WebSocket pipeline could be exercised offline, without an API key, and reproducibly — the dependency that would otherwise make the suite slow, costly and flaky.
    • Worked in Scrum with tests derived from the non-functional requirements (testability, latency under 2 s), documented per module in the sprint reports, with regressions caught by CI rather than by review.
    • Measured beyond the test suite: 94% routing accuracy over 100 labelled requests, and latency across 50 runs with a client-side harness.
    • Security enforced in CI: pip-audit and npm audit on every build, plus tests for the rate limiter and the WebSocket origin check alongside the prompt-injection defenses.

    Voice Vibe latency benchmark

    SystemArchitectureEnd-to-end latency
    OpenAI Realtime / GPT-4o voicenative speech-to-speech< 400 ms
    Retell AIcascade≈ 600 ms
    Vapicascade≈ 700–1500 ms
    Pipecat / LiveKit Agentscascade≈ 750–950 ms
    Voice Vibecascade + multi-agent≈ 975–1020 ms (p50)
    Synthflowcascade≈ 1800 ms
    End-to-end latency, voice in to voice out. Native speech-to-speech models skip the STT and TTS hops entirely, which is why they sit below every cascade system here. Voice Vibe is the only entry running a six-agent graph on each turn.
    • FastAPI
    • LangGraph
    • PostgreSQL
    • LightGBM
    • MLflow
    • DVC
    • Docker
    • GitHub Actions
    • pytest

Selected work

Four systems, taken from problem to production.

Each one is written up as a case study: what the problem actually was, what I built, and what it changed.

RAG evaluation · Research tooling

2026

RAGlign

Point it at your documents and it tells you which RAG configuration to use — and proves it.

Problem

Building RAG means choosing a chunking strategy, a retriever, and whether to rerank. Those choices interact, the right answer depends on your documents, and most teams pick by intuition. Measuring instead does not help as much as it should, because the standard measurement is biased: ground truth is recorded as a chunk ID, but chunk 57 only exists inside one chunking strategy. Score a different strategy against it and you are measuring how similar its cut points are, not how well it retrieves.

Contribution

I stored ground truth as a character span in the original document rather than a chunk ID, so every strategy is asked the same question — did you retrieve the text that answers this? — and none of them wrote the question. Around that I built a grid of 30 configurations, bootstrap confidence intervals on every metric, a per-question diagnosis naming the stage that lost it, and a dashboard that re-ranks live as you change what you value.

configurations evaluated
0configurations evaluated
hit@5 of measured bias
0.6hit@5 of measured bias
retrieval ↔ answer quality
+0.95retrieval ↔ answer quality
  • Python
  • sentence-transformers
  • BM25
  • NumPy
  • Streamlit
  • pytest
  • bootstrap CIs
Read case study

Architecture

Ground truth

Corpus
  • documents
  • ~40 questions
  • verbatim quotes
Spans
  • quote resolved to character span
  • offset invariant asserted

Evaluation

Grid
  • 5 chunkers
  • 3 retrievers
  • reranker on / off
Scoring
  • span overlap
  • hit@k
  • MRR
  • nDCG
  • bootstrap CIs

Analysis

Diagnosis
  • chunker destroyed / degraded
  • retriever missed
  • reranker demoted
Ranking
  • quality / latency / context weights
  • templated explanation
Surface
  • Streamlit dashboard
  • CLI scripts

Test automation · End-to-end QA

Oct 2025 — Jan 2026

Carpooling Test Automation

A test strategy and end-to-end suite over a carpooling web application, from requirements to anomaly tracking.

Problem

The value of a carpooling app lives in journeys that cross several features at once: a passenger joins a trip, the driver confirms, the trip completes, and only then does a debt appear between two people. Unit tests on either side of the API cannot reach that. End-to-end tests can, but they are also the first suite a team deletes, because they break on every markup change and fail intermittently on asynchronous updates.

Contribution

I owned the whole activity, not just the scripts. It starts upstream: analysing the requirements and functional specifications to define a test strategy, then writing the test plans, test cases and data sets that strategy implies. On top of that I built and maintained the framework — page objects owning their selectors and exposing intent-level methods, explicit waits instead of sleeps, data-driven cases — covering authentication, vehicles, trips, friends, debts and the key journeys. A Postman collection tests the REST API as a second layer, functional and regression runs execute in GitLab CI, and anomalies and test campaigns are tracked in Jira.

functional areas covered
0functional areas covered
test layers
UI + APItest layers
test architecture
POMtest architecture
  • Selenium
  • WebDriver
  • Python
  • Pytest
  • Page Object Model
  • Postman
  • GitLab CI
  • Jira
Read case study

Architecture

Test strategy

Requirements
  • requirements analysis
  • functional specifications
Plans
  • test plans
  • test cases
  • data sets

Test framework

Driver
  • Selenium WebDriver
  • browser session
Pages
  • Page Object Model
  • reusable components
Synchronisation
  • explicit waits
  • UI-level assertions
Cases
  • pytest fixtures
  • data-driven cases

Suites

Coverage
  • authentication
  • vehicles
  • trips
  • friends
  • debts
  • key journeys
API
  • Postman REST collections

Continuous integration

Pipeline
  • GitLab CI
  • functional + regression runs
Tracking
  • Jira: anomalies & test campaigns

Computer vision · Real-time systems

2025

Intelligent Traffic Monitoring

Vehicle detection, tracking, plate capture and homography-based speed estimation from video.

Problem

A speed measured in pixels is not a speed, and detection alone loses a vehicle the moment it passes behind a larger one. Without identity across frames and a mapping from the camera view to real distance, none of the numbers a traffic operator needs can be trusted.

Contribution

I built the pipeline end to end: YOLOv8 detects vehicles, ByteTrack holds their identity across frames, a second YOLOv8 model finds plates inside each vehicle crop, and a nine-point homography converts pixel positions into real-world coordinates so speed becomes an actual measurement. Violations are then flagged against limits that differ per vehicle type.

FPS sustained
0FPS sustained
speed estimation accuracy
98.6%speed estimation accuracy
point homography calibration
0point homography calibration
  • YOLOv8
  • ByteTrack
  • Supervision
  • FastAPI
  • WebSocket
  • Redis
  • Celery
  • Streamlit
  • Prometheus
  • Grafana
  • MLflow
  • Docker
  • pytest
Read case study

Architecture

Ingest
  • video upload
  • FastAPI
  • Redis queue
  • Celery workers
Detect
  • YOLOv8 vehicles
  • ByteTrack
Plates
  • YOLOv8 plate detector
  • quality assessor
  • best-shot storage
Measure
  • 9-point homography
  • outlier rejection
  • per-class speed limits
Observe
  • Prometheus
  • Grafana
  • MLflow
Present
  • Streamlit
  • WebSocket updates

Multimodal · Data engineering · Accessibility

2025

Sign Bridge

Speech, text and video translated into sign language by a 3D avatar.

Problem

Sign language is not a word-for-word encoding of speech. A literal transcription produces something a deaf user cannot read, so translation has to happen at the level of meaning.

Contribution

I built it in three parts. An offline data pipeline turned a corpus of human signing video into motion data: preprocessing, then OpenPose over every frame to emit per-frame keypoint JSON that Unity can drive an avatar from. A FastAPI backend normalises speech, text and video into one representation and maps it to sign gloss through a BERT-based NLP stage, with Whisper transcribing spoken input. A Unity client renders the 3D avatar from those keypoints.

sentences in vocabulary
32ksentences in vocabulary
individual words
4kindividual words
input modalities
0input modalities
  • FastAPI
  • Whisper
  • BERT
  • Transformers
  • OpenPose
  • Unity
  • NLTK
  • PostgreSQL
  • Pandas
Read case study

Architecture

Offline data pipeline

Corpus
  • signed video corpus
  • 32k sentences
  • 4k words
Preprocess
  • cleaning
  • per-frame extraction
Keypoints
  • OpenPose
  • per-frame keypoint JSON

Request path

Input
  • speech
  • text
  • video
Transcribe
  • Whisper STT
Understanding
  • BERT
  • NLTK
Mapping
  • sign gloss
Render
  • Unity 3D avatar
  • keypoint-driven

Approach

How I build.

Five principles that survive contact with production.

Architecture

Design modular systems with explicit boundaries, so a component can be replaced without a rewrite and a failure isolates to one place.

AI Engineering

Treat a language model as a component with a contract, not a black box that gets prompted harder when it misbehaves.

Performance

Measure latency, throughput and resource use before optimising. The slowest stage is rarely the suspected one.

MLOps

Track experiments, data and model versions so a result is reproducible, and gate releases so a regression is caught before users find it.

Security

Validate at the boundary, isolate execution, and instrument enough to notice when something is wrong.

Skills

The stack I actually reach for.

Grouped by the layer of the system they belong to.

Test & Quality

Test strategy, coverage, and the harnesses that make a result reproducible.

  • Pytest
  • Selenium
  • Page Object Model
  • pytest-cov
  • Unit / functional / integration / E2E
  • Regression testing
  • Test doubles (fakes, mocks)
  • Test plans & test cases
  • Requirements & specification analysis
  • Postman
  • Jira
  • GitHub Actions CI
  • GitLab CI
  • LLM & RAG evaluation
  • Latency measurement
  • Agile / Scrum

AI / Machine Learning

Agent graphs, retrieval, transformers and vision models.

  • LangGraph
  • LangChain
  • RAG
  • Multi-Agent Orchestration
  • Transformers
  • BERT
  • PyTorch
  • YOLO
  • OpenCV
  • ByteTrack
  • Mistral
  • DeepSeek
  • Scikit-learn
  • LightGBM

Backend

Services, transports and the data stores behind them.

  • Python
  • FastAPI
  • Spring Boot
  • Java
  • WebSocket
  • PostgreSQL
  • MySQL
  • DynamoDB
  • Redis
  • Celery

Frontend

Typed interfaces over the systems above.

  • Next.js
  • React
  • TypeScript
  • JavaScript
  • Angular
  • Tailwind CSS

MLOps / LLMOps

Experiment tracking, versioning, CI and release gates.

  • MLflow
  • DVC
  • ZenML
  • Docker
  • GitHub Actions
  • CI/CD
  • Prometheus
  • Grafana
  • pytest

Cloud / Infrastructure

Where it runs, and what it costs to keep running.

  • AWS
  • AWS Lambda
  • Linux
  • CUDA
  • Google Gen AI Toolbox
  • Google Colab

Contact

Open to AI and LLM engineering roles.

Based in Sousse, Tunisia — open to remote and relocation. The fastest way to reach me is email.

Education

  • Engineering Degree in Computer Science

    ENSI, Manouba

    2023 — 2026

  • Preparatory Scientific Cycle — Mathematics and Physics

    ESSTHS, Hammam Sousse

    2021 — 2023

Languages

  • EnglishAdvanced
  • FrenchAdvanced
  • ArabicNative