The three-year plan I give first-years

When I spoke at a BCA induction for 100+ first-years, the single most useful thing I could offer was a plan with years on it.

• Year 1: foundations and one shipped project. Python well enough to read library code, one web app with a database and a URL, and the habit of pushing to GitHub every day. Not forty technologies. One finished thing.

• Year 2: hackathons, internships, building in public. Two or three hackathons as a team that has stopped overlapping, one internship or two freelance projects, and a public record of what you built and what broke.

• Year 3: a deliberate choice. Placements, a startup or higher studies, chosen with evidence from Years 1 and 2 rather than by default.

Everything below is what fills those years for someone who wants to work in GenAI.

RAG: the five things a student project needs

Most student RAG demos are four steps: chunk, embed, retrieve, generate. They work on the demo question and fall apart on the second real one. Production RAG, the kind I built for clients, needs five more things.

1. Structure-aware chunking. Never split a table, a code block or a numbered procedure. Prepend the section heading to every chunk beneath it, so a chunk that says "the limit is 5 requests per second" also carries "Section 4.2: Rate limits". This one change did more for answer accuracy than any embedding model swap.

2. Hybrid retrieval. Vector search is good at meaning and bad at exact strings: product names, error codes, numbers. Run BM25 keyword search alongside dense search and merge the ranked lists with Reciprocal Rank Fusion. RRF avoids the score-normalisation problem entirely because it combines rank positions, not score magnitudes.

def rrf(ranked_lists, k=60):
    """Reciprocal Rank Fusion over several ranked lists of chunk ids."""
    scores = {}
    for ranked in ranked_lists:
        for rank, chunk_id in enumerate(ranked, start=1):
            scores[chunk_id] = scores.get(chunk_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

fused = rrf([dense_results, bm25_results])[:30]

3. A reranker. A cross-encoder reads the query and each candidate passage together and rescores the top 20 to 50. It catches negations, conditions and entities that a bi-encoder blurs. It is the highest-leverage component after chunking.

4. A confidence gate. If the best reranked score is below a threshold, refuse. My platform says "I don't know" on purpose, because a fluent wrong answer is the worst failure a retrieval system can have. Tune the threshold on a set of questions your documents cannot answer.

def answer(query, retriever, reranker, llm, threshold=0.35):
    candidates = retriever.search(query, k=30)
    ranked = reranker.rerank(query, candidates)[:5]
    if not ranked or ranked[0].score < threshold:
        return {"answer": None, "reason": "no supporting evidence", "sources": []}
    return llm.generate(query, context=ranked, cite=True)

5. Citations. Give every chunk a stable identifier that encodes document, page and position, present chunks with those identifiers in the prompt, and resolve the markers back to clickable sources. A reader should be able to check any sentence in ten seconds.

And before any of it: write 50 questions with known answers first. Retrieval recall, faithfulness and refusal accuracy on that set are the only way to know whether a change helped. Every improvement I have made to a RAG system was justified by a number on a fixed evaluation set, never by a feeling.

Fine-tuning on a student budget

Every fine-tuning tutorial assumes an A100. The fine-tuning platform I built trains a 1.7B-parameter model at about 3.2 GB of VRAM, which is hardware a student can borrow or rent for almost nothing. The method is QLoRA: load the frozen base model in 4-bit precision, train small low-rank adapters on top.

from peft import LoraConfig

config = LoraConfig(
    r=16,                     # adapter rank; 8-16 is plenty for format and tone
    lora_alpha=32,            # a sensible pairing is alpha = 2 * r
    lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    task_type="CAUSAL_LM",
)

Three things matter far more than the remaining hyperparameters.

• Validate the dataset before you burn a GPU hour. Malformed records, duplicated examples and a prompt template that does not match the base model's chat template ruin more runs than any learning rate. Render twenty random examples through the exact template and read them.

• Watch evaluation loss, not training loss. Training loss goes down whether or not the model is getting better. Hold out 5 to 10 percent of the data, evaluate every few hundred steps, and keep the checkpoint where evaluation loss was lowest.

• Compare base against tuned on the same held-out prompts. If you cannot show side by side that the tuned model is better on the task you care about, you do not have a result. You have a folder.

Also know when not to fine-tune. If the failure goes away when you paste the right document into the prompt, it is a retrieval problem. Fine-tuning changes behaviour and style; it does not reliably install facts, and it certainly does not update them.

Hackathons: what wins, from both sides of the table

In one year my team won first prize at Changethon at IIT Roorkee with an AI agribot for farmers, at Product Genesis at CSJMU with a pitch for small-business marketing, and at a MeetKats hackathon with a real-time food-sharing platform. We also built STROT over two sleepless nights and did not win. The loss taught me more than the wins, and it is why I now evaluate student projects with a written rubric rather than an impression.

What judges are actually scoring, in roughly this order:

1. A real problem for a real person. Name the user, the situation and what goes wrong today. If the judge cannot repeat your problem back in one sentence, the rest is noise.

2. A demo that works live, on input the judge suggests. A narrow working feature beats a broad slide deck every time. If it breaks, say what broke, technically, and continue.

3. A deliberate trade-off. "We dropped the mobile app to get the matching logic right" is the sentence judges remember. Teams that built everything halfway look like a to-do list.

4. Whether the team can build it. Let the person who built each part answer questions about it.

5. Viability beyond the weekend. A small, specific next step beats a grand vague one.

For teams: decide one demo path in the first two hours, freeze features two hours before judging, and rehearse the pitch with a timer as many times as you test the code. For organisers: publish the rubric with the problem statements, brief the judges together before the first pitch, and give every team two written sentences of feedback tied to a criterion. That feedback is the part students keep.

Shipping: the unglamorous half

Every AI product I have shipped uses the same shape: a FastAPI service that owns models, retrieval and data, and a Next.js front end that owns what the user sees. Python has the AI ecosystem; TypeScript has the browser. Put each where its tools live.

The parts students skip, and the parts that decide whether a project survives its demo day:

• Streaming. A ten-second wait followed by a wall of text feels broken; the same answer streamed word by word feels fast. Server-Sent Events over FastAPI is the simplest way.

• A fallback provider. Every LLM provider has bad hours. Put providers behind one interface, translate prompts inside the adapter, and fall back on hard failures. Cap what fallback can spend.

• Structured logs. Request id, model, tokens, latency, retrieval scores. Never raw personal data. The first time a client asks why an answer was wrong, this is what you will need.

• A memory budget. A reranker, an embedding model and a web server do not fit on a free-tier box by accident. Write the budget down before the outage teaches you to.

• Secrets that never reach the browser. All model calls go through your own API, which holds the key. A front end calling a provider directly is publishing your key to anyone with developer tools open.

Privacy deserves its own line. One of my systems does face detection, recognition and liveness checks entirely in the browser with ONNX Runtime Web, and the server stores only numeric embeddings, never images. Deciding what you refuse to store is an architecture decision, and it is the one that lets a college or a clinic trust your product.

How I mentor, and how to get the most out of a mentor

The sessions that worked, on campus and online, share a format: open with a problem the room recognises, build something live and make a mistake on purpose, give everyone fifteen minutes to do one small task on their own laptop, put three volunteers' results on the projector, and only then show slides. No slide before minute seventy. Something for the room to do every fifteen minutes.

The students who get the most from mentors share habits too. They show work, not intentions. They ask one specific question with what they already tried. They close the loop afterwards with what happened. And they help the year below them, which is how a community of a few students at one college became 500+ members across AI, web, security, data and startups.

If you want a session at your college

I speak at inductions and fests, run hands-on GenAI workshops where every student leaves with something deployed, hold mentorship sessions built around students' own projects, and judge student hackathons with the rubric above and written feedback for every team. Sessions for student communities are free; on-site visits anywhere in India ask only for travel. Coordinators can write to pranjulrathour41@gmail.com with the students' year, what they already know, and two or three date options.

More of my writing, including longer versions of every section above, lives on my portfolio and blog. The code is on GitHub, and I post about sessions and hackathons on LinkedIn.

Build one small thing this month. Ship it. Show someone. That is the whole method.