I’m Syed Hamza Tahir. I build production AI systems, from retrieval and agent workflows to evaluation and monitoring. Based in Islamabad, I work with teams worldwide.
I build data pipelines, train and deploy models, and give agents the tools and memory to act.
Data & Models
Turning data into model inputs
SourcesIngestion and orchestrationFeature engineeringVector storageOrchestrates
PyTorch
importtorchfromtorchimportnnimporttorch.nn.functional asFclassTwinTower(nn.Module):
def__init__(self, dim=384):
super().__init__()
self.tower = nn.Sequential(
nn.Linear(dim, 128), nn.ReLU(),
nn.Linear(128, 64),
)
defforward(self, a, b):
# Shared weights for both inputs# Unit vectors make cosine a dot product
a = F.normalize(self.tower(a), dim=-1)
b = F.normalize(self.tower(b), dim=-1)
return10 * (a * b).sum(dim=-1)
defpredict(self, a, b):
# Convert the score to a probabilityreturnself(a, b).sigmoid()
model = TwinTower()
optimizer = torch.optim.AdamW(
model.parameters(), lr=1e-3
)
# Loss uses raw logits, before sigmoid
loss_fn = nn.BCEWithLogitsLoss()
model.train()
# Paired embeddings; 1 = match, 0 = no matchfor a, b, label in loader:
optimizer.zero_grad()
logits = model(a, b)
loss = loss_fn(logits, label.float())
loss.backward()
optimizer.step()
model.eval()
withtorch.no_grad():
probability = model.predict(a, b)
Same weights
1 / 3
SelectedWork
I’ve built AI systems across healthcare, finance, research, and enterprise software.
Pharma
Solstice Health
FinTech
ChainGPT
Health
Femverse
Research
ResearchSoup
Safety
Forwood
Services
From raw data to production AI. I build the pipeline, the models, and the systems around them.
Most projects die before a model is chosen.
The data exists. The signal doesn’t. Feed that gap to a retriever and it returns noise; feed it to a fine-tune and you’ve baked the noise in permanently.
There’s no standard fix. It depends on what the model needs to learn. Sometimes that means pulling clean structure out of documents built for humans. Sometimes it means generating training pairs from unlabeled text. Sometimes it means throwing most of the corpus away.
That last one is equal parts engineering and judgment, and it’s the part nobody wants to own. I do.
Do that first and the model question gets smaller.
Document extractionData pipelinesTraining set constructionRAG ingestion
Defaults are expensive.
Reaching for the largest general model keeps charging you, per call, per second of latency, every time it does something you can’t explain. The requirement rarely needs it. It needs one thing done reliably, at a price that survives scale.
The answer is composition rather than escalation. Use a small model fine-tuned on your data, a specialist for the one hard subtask, an API model where breadth pays. Knowing which is which comes from measuring, not preference. The measurement has to exist before the model is chosen, or you’re just picking a favorite.
Model selectionFine-tuningEval harnessesCost & latency tuning
The model is the unreliable part.
Every system built on a probabilistic component needs a deterministic frame around it. Instructions in a prompt are requests. Constraints in code are guarantees. They decide what a step is allowed to reach, when a loop is permitted to stop, whether an answer ships without the evidence it claims to rest on.
The difference only shows up under load. A system that trusts the model to report its own progress works until the day it doesn’t, and then fails in a way nobody can reconstruct afterwards. One that tracks that state independently fails visibly, somewhere you can find it. Same model, same prompts. Different system.
Nothing about a deployed AI system holds still. The provider deprecates the model you built on. Your data drifts away from what you tested against. Users find inputs you never imagined. The system that passed evaluation in March is a different system by September, and it didn’t tell you.
Which is why the eval suite matters more after launch than before it, and why every run needs a trace someone can read. You want to catch the degradation on a dashboard rather than in a complaint. For the decisions where being wrong is expensive, you want a person in the path, given enough context to judge quickly.
Yes. I work across data preparation, retrieval pipelines, model selection, orchestration, product integration, evaluation, and deployment. We start by defining the business outcome, the constraints, and what success looks like. That gives the whole pipeline a clear target, with agreed milestones and ownership at each stage.
I start with representative inputs and a measurable baseline. RAG helps when answers need current, traceable knowledge; fine-tuning can improve a specific learned behavior; agents make sense when the task requires tools and multiple steps. I test the simplest approach against your requirements before adding complexity. Sometimes the right answer needs no model at all.
We agree on acceptance criteria before choosing the model: output quality, failure tolerance, latency, and cost. I build evaluations around real examples and difficult edge cases, then test the complete workflow, including integrations and failure recovery. Launch is a controlled rollout with traces, monitoring, and a rollback path.
I measure them together on your workload. That makes trade-offs visible: a smaller model may meet the quality target, better retrieval may save more than a larger context window, and caching or batching may reduce repeated work. The target is an agreed quality level at a response time and cost that make sense at your expected volume.
I map the existing APIs, deployment environment, identity controls, and data boundaries before designing the integration. Retrieval and tools should respect the permissions of the person using them. Hosting, model providers, retention, and logging are chosen around your requirements, with sensitive data kept out of places it does not need to go.
We agree on the handover deliverables up front: source code, deployment configuration, data and model dependencies, evaluation suites, architecture notes, and operating runbooks. I walk your team through how to deploy, diagnose failures, and make changes safely, so they can operate the system without depending on me for every decision.
The evaluation suite becomes the check for every change. Versioned prompts, models, and data pipelines make regressions easier to trace; production monitoring helps reveal drift, failures, and cost increases. We define who owns alerts and maintenance at handover, and agree separately on any ongoing support or improvement work.
Bring the idea. I’ll build the AI.
I build the data pipelines, models, and agents—and get them running in production.
