Samuel GarcíaAI / Software Engineer
GitHub (opens in a new tab)Contact

Open to AI Engineer, Applied ML and Software Engineer roles

Building intelligent systems.
Proving what works.

I am Samuel García, an AI and software engineer in Madrid. My work sits where retrieval, optimisation and evaluation have to survive contact with reality: research software with published protocols, product systems with inspectable evidence, and infrastructure that makes results reproducible.

Inspect the work GitHub Download résumé
Research
CAEPIA 2026 · dynamic multiobjective optimisation
Education
MSc AI, UPM · BSc Mathematics & Computer Engineering, Granada
FIG. 01 / ADR-EDA / QUALITY ÷ COST PUBLISHED BENCHMARK
Mean MIGD against mean runtime for eight dynamic optimisation methods ADR-EDA has the lowest mean MIGD at 0.3748 and the highest mean runtime at 204.3 seconds. SGEA is faster at 7.6 seconds but has a higher MIGD of 0.6829. Lower is better on both axes. ADR-EDA: MIGD 0.3748, MHV 5.3607, post-change IGD 0.2780, runtime 204.3 s DNSGA-II-B: MIGD 1.1113, MHV 4.9528, post-change IGD 1.5801, runtime 23.8 s MNSGA-II: MIGD 1.1731, MHV 4.6152, post-change IGD 1.4922, runtime 25.6 s SGEA: MIGD 0.6829, MHV 5.1786, post-change IGD 0.9610, runtime 7.6 s Tr-NSGA-II: MIGD 0.6112, MHV 4.7203, post-change IGD 0.2192, runtime 28.6 s PFPA: MIGD 1.2935, MHV 4.1596, post-change IGD 1.3091, runtime 4.7 s TDA-DMOEA: MIGD 1.2624, MHV 4.3670, post-change IGD 1.9564, runtime 2.1 s AB-DMOEA: MIGD 1.1306, MHV 4.7017, post-change IGD 1.6677, runtime 3.6 s
MIGD0.3748
RUNTIME204.3 s
PROTOCOL14 × 15
ADR-EDA has the lowest mean MIGD in the published protocol, and the highest runtime. The frontier is the finding; the cost is part of it.Source ↗
0.3748ADR-EDA mean MIGDbest of eight methods · 14 problems × 15 seeds
20.6%FinRAG holdout Hit@5MiniLM · evidence coverage, not answer accuracy
0.645QuantLab SharpeH001 · vs 0.459 baseline at 10 bps
RealJobLens evaluatorreport computed by Python, not mock JSON

SELECTED WORK / 04

Built to be inspected.

Four systems with different engineering problems: adaptive optimisation, inspectable retrieval, quantitative backtesting and evidence-first product UX. Every claim links to its public repository.

01 / RESEARCH SOFTWARE

ADR-EDA

Designed and built the controller, benchmark harness and reproducibility workflow.

Problem

After an environmental change, an optimiser can blindly reuse inherited state and suffer negative transfer, or restart and discard useful information. The useful question is how much state to trust.

Approach

Blind reuse risks negative transfer; restarting throws away useful information. ADR-EDA separates mean and covariance change evidence, estimates severity, allocates a response, and checks its quality before model learning continues.

  1. Mean and covariance change evidence
  2. Smoothed severity and response context
  3. Response allocation: continuity, prediction, diversity, local search
  4. Quality safeguard against a pre-intervention reference
  5. Accept the response or preserve the incumbent state
Mean MIGD
0.3748 best of 8 compared methods in the published protocol
Mean MHV
5.3607 best mean global MHV in the same protocol
Runtime
204.3 s vs 7.6 s for SGEA — the quality has a cost
Case study Repository Benchmark results

Accepted at CAEPIA 2026 / Springer proceedings. Evaluated on 14 problems × 15 seeds; ADR-EDA wins 6/14 on MIGD and 7/14 on MHV. Post-change IGD is better for Tr-NSGA-II. These are protocol-specific results, not universal superiority.

TRADE-OFF TABLE / 8 METHODSLOWER IS BETTER ON BOTH AXES
MethodMIGDMHVPost-change IGDRuntime
ADR-EDA0.37485.36070.2780204.3 s
Tr-NSGA-II0.61124.72030.219228.6 s
SGEA0.68295.17860.96107.6 s
DNSGA-II-B1.11134.95281.580123.8 s

ADR-EDA wins 6/14 problems on MIGD and 7/14 on MHV. Tr-NSGA-II has better immediate post-change IGD. These are protocol-specific results.

FinRAG answering an AMD FY2022 revenue question with source evidence from PDF page 48.
Authentic local-inference screenshot from the FinRAG repository.
RETRIEVAL COVERAGE / FINANCEBENCHALL-EVIDENCE HIT@5

Retrieval coverage, not answer accuracy. The holdout drop is the finding.

02 / APPLIED RETRIEVAL

FinRAG

Built the retrieval pipeline, retrieval evaluation, FastAPI service and React evidence workspace.

Problem

A financial answer can require facts from several pages and correct arithmetic. Retrieving plausible passages is not the same as producing a correct, checkable answer.

Approach

The workspace lets a user read an answer, inspect the passages behind every citation, and open the original report at the referenced page. A sparse-versus-dense comparison makes retrieval behaviour visible instead of hiding it behind a chat box.

  1. PDF extraction with page and source provenance
  2. TF-IDF, MiniLM and Multi-Query retrieval
  3. FastAPI service and React evidence workspace
  4. Local Qwen generation with explicit response states
Holdout Hit@5
20.6% MiniLM · 34 questions · evidence coverage, not answer accuracy
Pilot Hit@5
46.4% the drop to holdout is the finding, not a footnote
Tests
146 Python tests passing at the recorded Oct 2026 check; 17 browser tests also passed
Case study Repository Evaluation detail

FinanceBench all-evidence Hit@5 uses separate pilot (28 questions, 6 reports) and holdout (34 questions, 10 reports) evaluations. Retrieval coverage is not end-to-end correctness; the system is a local research application, not a hosted service.

03 / QUANTITATIVE ENGINEERING

QuantLab

Designed the experiment, execution model, transaction-cost treatment and exposure-matched control.

Problem

Does a time-series momentum risk gate improve risk-adjusted behaviour, or is the apparent improvement only the result of sitting in cash?

Approach

The interesting control is ExposureMatched: it holds the baseline allocation but matches H001’s target ETF exposure at every rebalance. That separates part of the effect of sitting in cash from the momentum gate itself.

  1. Eight-ETF inverse-volatility baseline
  2. 252-session excess-momentum filter with a cash leg
  3. Next-close execution and proportional transaction costs
  4. Exposure-matched control for attribution
Sharpe · H001
0.645 vs 0.459 baseline and 0.555 exposure-matched
Max drawdown
−11.0% vs −26.0% baseline, at 10 bps costs
CAGR
4.89% baseline is higher at 5.20% — no free lunch claimed
Case study Repository Experiment notes

Historical descriptive results, not evidence of alpha or future profitability. Next-close execution, proportional 10 bps costs, no pristine out-of-sample set. The exposure-matched portfolio is an attribution control, not an exact daily risk match.

WEALTH AND DRAWDOWN / H00110 BPS · 2008–2026

Derived from the published H001 wealth series. H001 has lower historical volatility and maximum drawdown, but the baseline has higher CAGR.

COST SENSITIVITY0, 5, 10, 20 BPS

The main risk-adjusted pattern remains present across all four cost scenarios. The 10 bps figures are shown above; the experiment also reports four subperiods and a nine-combination parameter grid.

JobLens desktop overview with candidate and posting controls.
Authentic screenshot from the JobLens public demo.
JobLens evidence report showing documented requirements and review gates.
EVIDENCE REPORT / SYNTHETIC EXAMPLENO SCORE, NO PREDICTION
EVIDENCE REPORTSYNTHETIC EXAMPLE
  • Documented5 / 5 required
  • Tag only0 / 2 preferred
  • Evidence gapshown as a gap
  • Human review4 gates surfaced

No score. No prediction. The report separates documented evidence from what still needs a human.

04 / PRODUCT ENGINEERING

JobLens

Designed the evaluator interface, loopback API and the evidence-state model.

Problem

Job matching is often reduced to a score. A useful report should show what is documented, what is only a tag, what is missing and what still needs a human decision.

Approach

No hiring score. No probability of an interview. The report shows the exact evidence claim and source path behind a match, and surfaces degree, authorisation and experience gates instead of hiding them in a number.

  1. Python evaluator computes the report
  2. Loopback API with host, origin and token checks
  3. Restrictive CSP and no-store responses
  4. Exact claim text, reference id and source path in the report
Report basis
Real evaluator the browser receives a computed report, not mock JSON
Runtime deps
0 Python standard library only for the public demo
Boundary
Loopback host/origin/token checks, CSP, no request logging of pasted text
Case study Repository Demo notes

The public demo uses fictional candidates and synthetic postings. Coverage means documented evidence in that bank — not ability, seniority or likelihood of an interview. Not an ATS or a hiring predictor.

OPERATING PRINCIPLES

The work is the evidence.

Outputs are easy to show. The part that matters is the protocol, the control, the source and the stated limit.

01

Claims need a protocol

Seeds, splits, cost assumptions and baselines are part of the result. If the protocol is weak, the number is decoration.

02

Evaluation is a product feature

Citations should open the source page. A gap should look like a gap. Review gates should be visible, not buried in a score.

03

Reproduce before improving

Docker, lockfiles, manifests and CI are not housekeeping. They are how a result becomes something another engineer can trust.

04

Name the limits

Every project above carries its constraints in public. A system that knows what it cannot do is easier to operate — and easier to improve.

FOUNDATIONS / 05

Range, with the same standard.

Additional repositories across mathematics, computer vision, NLP, robotics and reinforcement learning. Each publishes its own evidence and limits.

StochasticDiffusionC++ · Scientific computing

Parameter estimation for a stochastic multi-sigmoidal diffusion model using numerical, evolutionary and memetic optimisation.

4.49% max relative error in the reproducible demo · 210 historical runs across 7 optimisers

C++17 · Ceres · Eigen · Boost
SatelliteVisionComputer vision

13-class xView classification with a fine-tuned Swin Transformer, imbalance-aware training and four-view TTA.

83.20% validation accuracy · historical result; original checkpoint not preserved

PyTorch · Swin-Base · MixUp/CutMix
MarketNLPNLP · Model evaluation

Financial sentiment classification comparing a trained TF-IDF baseline with pretrained FinBERT on the same cleaned test texts.

TF-IDF 0.8043 accuracy / 0.6984 macro-F1 · FinBERT 0.7139 / 0.6584

scikit-learn · Transformers · FinBERT
RoboNavRobotics · Planning

ROS 2 occupancy mapping and navigation with log-odds grids, Bug2, Theta-style planning, Dijkstra and RRT.

Known-pose mapping, explicitly not SLAM · offline planner tests

ROS 2 Humble · CoppeliaSim · Python
DeepRL-LunarLanderReinforcement learning

A tested Double DQN agent with a dueling architecture, prioritised replay and importance-sampling weights.

268.32 mean return · 30 greedy episodes, one historical policy — no multi-seed claim

TensorFlow · Keras · Gymnasium

PROFILE

Research discipline. Product instincts.

EDUCATION

MSc Artificial Intelligence
Universidad Politécnica de Madrid
BSc Mathematics & Computer Engineering
University of Granada

I work between research software and product engineering: retrieval systems, optimisation, evaluation and the software that makes results inspectable.

My research focuses on dynamic multiobjective optimisation. My applied work spans RAG, scientific computing and quantitative simulation. The common thread is making claims survive inspection.

“The interesting question is not whether a model can answer. It is whether the answer can be checked.”

Associated paper: ADR-EDA: A reliability-aware controller for dynamic multiobjective estimation of distribution algorithms, accepted at CAEPIA 2026 / Springer proceedings. Thesis supervised by Concha Bielza Lozoya and Pedro Larrañaga Múgica.

Read the research repository

CONTACT

Have a hard problem?
Let's make it measurable.

Open to AI Engineer, Applied ML and Software Engineer roles where evaluation and engineering judgment matter as much as model choice. Based in Madrid.

samcarjes@gmail.com
Email LinkedIn GitHub Résumé (PDF)

Open to AI Engineer, Applied ML and Software Engineer roles