Build toward an interview ready GenAI portfolio.

Start with the right mental model: an LLM predicts tokens from context. It can be useful, but it can also be wrong, stale, or overconfident.

• Install: Python 3.10+, VS Code, Git, and one clean project workspace.
• Learn: the command line, virtual environments (venv or conda), and the four Git verbs you'll use forever — clone, commit, push, pull.
• Sign up: Google AI Studio, Hugging Face, and one hosted-model provider such as OpenAI, Anthropic, or Gemini. Use free tiers first; provider limits change, so always check current pricing before scaling.
• Profile setup: clear LinkedIn headline, simple portfolio page, and one clean project case study. Hiring starts before the first interview.

You do not need to master all of Python. You need enough to read files, call APIs, handle errors, and organize a small app.

• Variables, types, control flow, functions, classes.
• Files, JSON, CSV, environment variables, and HTTP APIs (requests).
• API basics: status codes, headers, auth tokens, timeouts, retries, pagination, and rate limits.
• numpy (arrays), pandas (tables), matplotlib (plots).
• Exception handling, list/dict comprehensions, f-strings, type hints, and light testing with pytest.
• Backend preview: build one tiny FastAPI endpoint so deployment later does not feel alien.

You don't need a math degree. You need to look at a paper's diagram and not feel lost.

• Linear algebra: vectors, matrices, dot products — and why "similarity" has a geometric meaning.
• Probability: distributions, expectation, why softmax exists.
• Calculus: what a gradient is and why "going downhill" trains a model.

Before you train a transformer, train a logistic regression. The vocabulary is the same.

• Supervised vs unsupervised vs reinforcement.
• Train/validation/test splits, overfitting, the bias-variance tradeoff.
• Data leakage, baseline models, feature quality, and why a bad split can make a weak model look brilliant.
• Metrics: accuracy, precision, recall, F1, MSE, perplexity. Pick the right one for the right task.
• scikit-learn on a small tabular dataset (Iris, Titanic) — feel the workflow.
• One neuron → forward pass → loss → backprop → gradient descent. Karpathy's micrograd is the gold standard.

Pick PyTorch. Train three small models. Move on. Don't build a custom CUDA kernel.

• Tensors, layers, activations (ReLU, GELU), losses, optimizers (SGD, Adam).
• One framework — PyTorch (every modern paper) or Keras.
• Build end-to-end: a tiny MLP for MNIST, a small CNN for CIFAR-10, a character-level RNN/Transformer for text.

Text becomes numbers, numbers become attention, attention becomes a model that finishes your sentence. Get the picture, not the matrix algebra.

flowchart LR
    T["Hello world"] -->|tokenizer| TOK["IDs: 15496, 995"]
    TOK -->|embedding lookup| EMB[("vectors
e.g. 768-dim each")]
    EMB --> ATT["Self-attention
each token looks at every other"]
    ATT --> FFN["Feed-forward
+ residuals + layer norm"]
    FFN -. repeat N layers .-> OUT["Logits over vocabulary"]
    OUT -->|argmax / sampling| NEXT["next token: '!'"]
    NEXT -. feed back .-> T

    classDef inn fill:#fffbeb,stroke:#fbbf24
    classDef proc fill:#eff6ff,stroke:#60a5fa
    classDef out fill:#ecfdf5,stroke:#34d399
    class T,TOK inn
    class EMB,ATT,FFN proc
    class OUT,NEXT out

• Tokenization: how text becomes numbers (BPE, SentencePiece). Words ≠ tokens.
• Embeddings: vectors that capture meaning. Similar meaning, similar vectors.
• Attention: the mechanism that lets a model "look at" earlier tokens with different weights.
• Encoder vs decoder vs encoder-decoder: BERT (encoder, understanding), GPT/Llama/Claude (decoder, generation), T5/BART (both).
• Hands-on: Hugging Face Transformers — load a model, run pipeline(...), inspect outputs.

An LLM is a tokenizer wrapped around a transformer wrapped around a prompt. Knowing the four knobs — context, tokens, temperature, top-p — covers most beginner app work.

flowchart LR
    P["Your prompt
+ system + history"] --> TOK["Tokenize
~4 chars per token"]
    TOK --> M["LLM
billions of parameters"]
    M --> LOG["Logits
score for every token
in the vocabulary"]
    LOG --> S{Sampling
strategy}
    S -->|temperature| OUT["Next token"]
    OUT -->|append + repeat| TOK
    OUT --> STOP["Stop on EOS
or max_tokens"]

    classDef inn fill:#fffbeb,stroke:#fbbf24
    classDef proc fill:#eff6ff,stroke:#60a5fa
    classDef out fill:#ecfdf5,stroke:#34d399
    class P,TOK inn
    class M,LOG,S proc
    class OUT,STOP out

• Pre-training (next-token prediction on the internet) → post-training (instruction tuning + RLHF/DPO to make it useful and safe).
• Open-weight vs closed: Llama, Mistral, Qwen, DeepSeek, Gemma (open) vs GPT, Claude, Gemini (closed APIs).
• Context window — how much text the model can "see". It varies by model and provider, so check current docs before designing around a limit.
• Tokens — the billing and length unit. ~1 token ≈ 4 English characters or ¾ of a word.
• Temperature — lower for factual/extraction tasks, higher for brainstorming and writing. Measure instead of guessing.
• top-p / top-k — alternative sampling controls. Stick with temperature unless you have a reason.
• API production basics: streaming, retries with backoff, timeout handling, rate-limit handling, model fallback, and per-request cost logging.
• Model choice: small/fast model for extraction and routing; stronger model for reasoning, coding, or hard synthesis. Measure instead of guessing.

Most "we need fine-tuning" problems are actually "we need a tighter prompt and a Pydantic schema."

• Zero-shot, few-shot, chain-of-thought.
• Roles: system (rules), user (input), assistant (response). Use them.
• Structured output: ask for JSON; better, use the model's structured-output mode (response_format, with_structured_output). Validate with Pydantic.
• Function / tool calling: the model returns which function to call with what arguments; your code runs it and feeds the result back.
• Prompt evals: save 20 tricky inputs, run them after every prompt change, and keep the prompt version in logs.
• Pitfalls: hallucinations, prompt injection (user input overrides system rules), context drift in long chats.

flowchart LR
    P[Prompt] --> M{Did it work?}
    M -->|Yes| DONE["Ship it"]
    M -->|Mostly. Bad format| P1["Tighten the prompt
+ JSON / Pydantic schema"]
    M -->|It does not know my data| RAG["Add RAG
Stage 8"]
    M -->|Wrong style/skill, even with examples| FT["Fine-tune
Stage 11"]
    P1 --> P
    RAG --> DONE
    FT --> DONE

    classDef good fill:#ecfdf5,stroke:#34d399
    classDef warn fill:#fffbeb,stroke:#fbbf24
    class DONE good
    class P1,RAG,FT warn

LLMs don't know your data. RAG fixes that without retraining anything — you bolt search onto generation and let the model quote from your docs.

flowchart LR
    subgraph INDEX["Build (offline, once)"]
        D[Your docs
PDFs, wiki, tickets] --> CH[Chunk
~300-800 tokens]
        CH --> EMB1[Embedding model
e.g. all-MiniLM-L6-v2]
        EMB1 --> VDB[(Vector DB
FAISS / Chroma / Qdrant)]
    end

    subgraph QUERY["Answer (every request)"]
        Q[User question] --> EMB2[Same embedding model]
        EMB2 --> SEARCH[Top-k similarity search]
        VDB --> SEARCH
        SEARCH --> CTX[Top chunks = context]
        CTX --> PROMPT[Prompt = system + context + question]
        PROMPT --> LLM[LLM]
        LLM --> A[Grounded answer
with citations]
    end

    classDef offline fill:#eff6ff,stroke:#60a5fa
    classDef online fill:#ecfdf5,stroke:#34d399
    class D,CH,EMB1,VDB offline
    class Q,EMB2,SEARCH,CTX,PROMPT,LLM,A online

• Why RAG: LLMs don't know your data and have a knowledge cutoff. Inject relevant snippets into the prompt at query time.
• Embeddings & vector DBs: FAISS (local, free), Chroma (simple), Qdrant (production OSS), Pinecone (managed).
• Chunking: start with RecursiveCharacterTextSplitter, ~500 tokens, ~50 overlap. Tune later.
• Re-ranking: add a cross-encoder (e.g. bge-reranker) on top-20 → top-3 for big quality wins.
• Hybrid search: combine keyword/BM25 with vector search when exact terms, IDs, or error codes matter.
• RAG evals: measure context recall, faithfulness, answer relevance, citation accuracy, and "I don't know" behavior.

The frameworks aren't magic. They're glue. Pick the one with the docs you can read and the failures you can debug.

• Orchestration: LangChain (broadest) or LlamaIndex (RAG-first). Pick one.
• Validation: Pydantic v2 — your defense against malformed LLM output.
• UIs in <50 lines: Gradio (great for ML demos) or Streamlit (great for dashboards).
• Observability: LangSmith, Langfuse, or Phoenix — see every prompt, response, and tool call.
• Model gateway: use LiteLLM or a thin adapter layer so switching between OpenAI, Anthropic, Gemini, and local models does not rewrite your app.
• Integration pattern: learn MCP basics if you want agents/tools to connect cleanly to external systems.
• Experiment tracking (optional): Weights & Biases, MLflow.

Agent = LLM + tools + memory + a loop. Most "agent failures" are actually loops without limits and tools without tests.

flowchart LR
    U[User goal] --> AG{LLM
plans next step}
    AG -->|"Thought:
I need to search the docs"| TOOL[Pick a tool
+ arguments]
    TOOL --> EXEC[Run tool
search / API / code]
    EXEC -->|Observation| AG
    AG -->|I have enough info| ANS[Final answer]

    classDef think fill:#fffbeb,stroke:#fbbf24
    classDef act fill:#eff6ff,stroke:#60a5fa
    classDef done fill:#ecfdf5,stroke:#34d399
    class AG think
    class TOOL,EXEC act
    class ANS done

• The ReAct pattern (Reason → Act → Observe → repeat) is the foundation.
• Tool use / function calling: the LLM emits a JSON call; your runtime executes it and returns the result.
• Frameworks: LangGraph (graphs and control), CrewAI (role-based), AutoGen (multi-agent chat), OpenAI Agents SDK.
• Tool quality: typed schemas, input validation, deterministic tool tests, clear errors, and a max-iteration budget.
• Memory: separate short-term conversation state from long-term user/profile memory; never store sensitive data by accident.
• Watch out for: infinite loops (always cap iterations), runaway costs (log every call), bad tools (a flaky tool poisons the whole agent).

Fine-tune for style, tone, domain language, format. Almost never for adding facts — that's RAG's job.

flowchart TD
    DATA["Curated dataset
500-5,000 examples"] --> SPLIT["Split
train / eval (80/20)"]
    SPLIT --> EVAL_BEFORE["Run baseline
measure metrics"]
    SPLIT --> TRAIN["LoRA / QLoRA training
1-4 epochs
1x consumer GPU"]
    TRAIN --> ADAPTER["Adapter weights
~10-100 MB
not full model"]
    ADAPTER --> MERGE["Merge or load
at inference time"]
    MERGE --> EVAL_AFTER["Re-run eval
compare to baseline"]
    EVAL_AFTER --> SHIP{Better
on YOUR metric?}
    SHIP -->|Yes| DEPLOY["Ship adapter"]
    SHIP -->|No, regressed| DATA
    SHIP -->|No change| PROMPT["Try better prompts
or RAG instead"]

    classDef data fill:#fffbeb,stroke:#fbbf24
    classDef train fill:#eff6ff,stroke:#60a5fa
    classDef eval fill:#f5f3ff,stroke:#a78bfa
    classDef done fill:#ecfdf5,stroke:#34d399
    class DATA,SPLIT data
    class TRAIN,ADAPTER,MERGE train
    class EVAL_BEFORE,EVAL_AFTER,SHIP eval
    class DEPLOY,PROMPT done

• LoRA / QLoRA — train a small "adapter" instead of the full model. Runs on a single consumer GPU.
• Datasets: quality > quantity. 500 hand-curated examples beat 50,000 noisy ones.
• Evaluation: build an eval set before you fine-tune. If you can't measure it, you can't improve it.
• Tools: Hugging Face peft + trl, Unsloth, Axolotl.

A demo on your laptop is a story. A public URL is a credential.

flowchart LR
    DEV[Notebook
that works] --> APP[FastAPI / Flask app
+ Pydantic schemas]
    APP --> DOCK[Dockerfile
requirements.txt]
    DOCK --> HOST{Where?}
    HOST --> HF["HF Spaces
simple demos"]
    HOST --> RND["Render
web app host"]
    HOST --> RAIL["Railway
web app host"]
    HOST --> CLOUD["AWS / GCP / Azure
full control"]

    APP --> OBS[Observability
LangSmith / Langfuse]
    APP --> GUARD[Guardrails
input/output filters]
    APP --> COST[Cost tracking
tokens x price]

    classDef green fill:#ecfdf5,stroke:#34d399
    classDef blue fill:#eff6ff,stroke:#60a5fa
    classDef yellow fill:#fffbeb,stroke:#fbbf24
    class HF,RND green
    class RAIL,CLOUD blue
    class OBS,GUARD,COST yellow

• Wrap your model in FastAPI. Validate input/output with Pydantic.
• Containerize with Docker so it runs the same everywhere.
• Low-cost hosting: Hugging Face Spaces, Render, and Railway. Check current free tiers, sleep policies, and pricing before relying on them.
• Production basics: secrets management, request queues, caching, background jobs, health checks, CI/CD, and rollback notes.
• Reliability basics: retry only safe operations, cap output tokens, add timeouts, and surface useful errors to users.

Treat user input as untrusted. Treat model output as confidently wrong until proven otherwise. Cite sources, log everything, and never paste PII into someone else's API.

flowchart LR
    USER["User input
(untrusted)"] --> GUARD1["Input guardrails
injection detection
PII redaction"]
    GUARD1 --> SYS["System prompt
+ retrieved context"]
    SYS --> LLM[LLM]
    LLM -->|may hallucinate| GUARD2["Output guardrails
schema validation
citation check
toxicity filter"]
    GUARD2 --> LOG["Log everything
prompt, response, tokens, cost"]
    LOG --> RESP["Response to user"]

    SECRET[("Sensitive data
PII, secrets, IP")] -. never send .-> LLM
    SECRET -->|use| LOCAL["Self-hosted model
Ollama / vLLM"]
    LOCAL --> GUARD2

    classDef danger fill:#fef2f2,stroke:#dc2626,color:#7f1d1d
    classDef guard fill:#fffbeb,stroke:#fbbf24
    classDef safe fill:#ecfdf5,stroke:#34d399
    class USER,SECRET danger
    class GUARD1,GUARD2,LOG guard
    class RESP,LOCAL safe

• Hallucinations: assume they happen. Cite sources, validate, add a confidence step.
• Prompt injection / jailbreaks: never let user input override system instructions for sensitive actions.
• Data leakage: don't send PII, secrets, or proprietary data to third-party APIs without consent. Self-host when in doubt.
• Bias & fairness: test across demographics; "default" outputs aren't neutral.
• Security baseline: know the OWASP Top 10 for LLM Apps and design around prompt injection, data exfiltration, excessive agency, and insecure plugins/tools.
• Evals & guardrails: Ragas, DeepEval, Guardrails AI, NeMo Guardrails.