Applied engineering and research directions for 3rd- and final-year CSE students
This guide turns the weekend's small prototypes into realistic college projects. The course gives you a starting artifact; it does not make a production system in two days. It also covers the part before the code: where ideas actually come from, how to pick one, how to form a team that survives the semester, and how to build with AI assistants without renting your own project.
Choose one user, one data source, one decision, and one measurable claim.
Bad scope:
Build an AI assistant for students.
Good scope:
Help the exam-cell assistant answer 40 recurring questions from the current regulations PDF, with citations, at least 85% answer accuracy on a 100-question test set, and a refusal when the answer is not in the document.
Good ideas are collected, not brainstormed. A 1 a.m. hostel brainstorm produces "AI assistant for students"; an hour of watching the exam cell produces a project. Go looking in this order, because the closer the source is to you, the better your data access, and data access decides projects.
One warning: an idea that arrives with no reachable user and no accessible data is not an idea. It is a tweet.
Run every candidate through these five before you commit anything.
And pick the problem, not the stack. Nobody grades you for using an agent framework. You are graded for a number.
These are seeds, not scopes. Each still has to pass the five tests, the gradeable rule, and ship the nine artifacts below. Steal freely, then narrow.
Photograph the day's mess board, extract the dishes, diff against the published weekly menu.
RAG over the current regulations PDF answering the 40 questions the exam cell hears daily, with citations and refusal.
Bilingual Q&A over the city and college bus charts, Tamil and English.
Embed found-item photos and lost-item descriptions, match across the modality gap.
Q&A over the master timetable: free rooms, staff clashes, lab overlaps.
Extract skills from job descriptions and cite which subject and unit covers each.
Bilingual college circulars to one-line summaries; dates and fees flagged, never paraphrased.
Vision check of a filled form against its instruction page, listing what will get it rejected.
Scanned lab record against the rubric: missing aim, missing output, unsigned pages.
Cluster five years of question papers by topic, citing question numbers per topic.
Unit-wise quizzes generated from your own notes with page citations.
"How many periods can I still miss?" answered only from the regulations, refusing when they are silent.
Event FAQ bot where the schedule changes hourly and answers carry timestamps.
"Where is this book, and is it in?" over a catalogue export.
Classify and route complaints to electrical, plumbing, wifi, or mess, with human approval before dispatch.
A local shop's handwritten ledger, often Tamil, to structured rows.
Multilingual RAG over official tourist information: Tamil, English, Hindi and one more.
Check student C or Python code against the department coding-standard sheet.
One course's recorded-lecture transcripts, answers with timestamp citations.
A weekly photo of the physical notice board into a deadline-sorted digest.
A polished UI without these artifacts is a demo. A modest UI with these artifacts is an engineering project.
Be honest about two things: the hours your whole team will truly spend, and what must exist at the end. Match them to a level; ambition one level above your hours does not label test sets.
These are small portfolio extensions.
| Project | Core techniques | Minimum evidence |
|---|---|---|
| Study-notes RAG | embeddings, retrieval, citations, evaluation | 20 questions, one baseline, one retrieval failure |
| Receipt/document extractor | vision, structured output, validation | field-level accuracy on 20 images or synthetic samples; unknown path for unreadable fields |
| Prompt evaluation dashboard | prompt versioning, regression tests, latency/cost logging | compare two prompts on a fixed test set and display failures |
These fit a mini-project or a guided lab series.
| Project | Core techniques | Minimum evidence |
|---|---|---|
| Department regulations assistant | RAG, citations, refusal, freshness, injection testing | 50 labelled questions, document dates, answer and retrieval metrics, poisoned-document test |
| Codebase RAG assistant | code chunking, semantic + keyword retrieval, citations | index one student repository, answer 30 code questions, cite file paths and line ranges |
| College document QA | multimodal extraction, schema validation, human review | marksheet/form/receipt pipeline, field-level confusion table, explicit rejection cases |
| Subject tutor for one course | RAG, quiz generation, evaluation, optional vision | one subject only, 30-question test set, source citations, weak-topic report |
| Tamil or multilingual scheme assistant | multilingual retrieval, token measurement, RAG, evaluation | parallel language questions, token/cost comparison, language-specific failure analysis |
These are suitable for a semester project when one team owns the scope.
| Project | Core techniques | Minimum evidence |
|---|---|---|
| LLM evaluation and observability dashboard | evals, traces, cost, latency, prompt versions | run history, p50/p99 latency, token/cost charts, regression alerts, privacy-safe logs |
| RAG + tools assistant with approval gates | RAG, function calling, workflow, validation, human approval | at least two read-only tools, one blocked side effect, step cap, tool-choice evaluation |
| Department knowledge service | ingestion pipeline, metadata filters, hybrid retrieval, deployment | update/re-index path, citations, access control, 100-question evaluation, hosted demo |
| Personal AI tutor for one subject | multimodal input, RAG, quiz/eval loop, user feedback | measurable learning task, baseline comparison, failure and bias analysis, privacy plan |
The team you form in week 1 decides more of your grade than the model you call in week 6.
Each of these sinks real teams every year.
Interview 3–5 users. Observe the current process. Collect only the documents you are allowed to use. Write one measurable claim.
Start with a plain prompt or manual workflow. Record where it fails. Do not add RAG, tools, or agents before you have a baseline.
Add one technique at a time: structured output, retrieval, or one read-only tool. Keep the system understandable enough to draw on a whiteboard.
Write labelled examples with a domain expert. Include ambiguous, unanswerable, multilingual, and adversarial cases. Freeze version 1 of the set.
Compare against the baseline. Separate retrieval failure from generation failure. Test prompt injection, stale documents, malformed output, timeouts, and quota errors.
Put the key server-side, add limits and logs, deploy a small interface, run a user trial, and document what you would not automate.
You will build this with AI assistants; the course itself assumes it. The difference between teams that AI accelerates and teams it sinks is a handful of habits, and examiners have learned to test for them.
PROMPTS.md in the repo with the prompts that produced committed code. At viva it converts suspicion into credit.These are not “build a chatbot” projects. Each one is an experiment with a hypothesis, a controlled comparison, a measurable result, and a reproducible artifact. A team should choose one track and implement a narrow version over a semester; do not attempt all the techniques listed in a row.
| Research track | Research question / hypothesis | Baselines and variables | Metrics and artifact |
|---|---|---|---|
| Multilingual and code-switched RAG | Does retrieval quality degrade when students ask the same question in English, Tamil, Tanglish, and Hindi? Does query translation improve recall without increasing hallucination? | Baselines: English-only dense retrieval and keyword search. Variables: language, translation, embedding model, chunking. | Recall@k, MRR, answer faithfulness, token/cost ratio, language-wise error report, reproducible multilingual benchmark. |
| Chunking and hybrid retrieval study | Does structure-aware chunking plus BM25+dense retrieval beat paragraph-only dense retrieval on college regulations and code? | Baselines: fixed-size chunks and dense-only search. Variables: chunk size, overlap, metadata filters, BM25 fusion, reranking. | Recall@k, MRR, nDCG, answer accuracy, latency, index size, ablation table, reusable retrieval benchmark. |
| Hallucination and abstention calibration | Can a system learn when to answer and when to say “I don’t know” without becoming uselessly evasive? | Baselines: always-answer prompt and grounded prompt. Variables: refusal threshold, retrieval score, verifier model, answer format. | Coverage, selective accuracy, abstention precision/recall, calibration curve, risk-weighted error, refusal/evidence dashboard. |
| Multimodal document QA robustness | Which image conditions cause structured extraction to fail: blur, skew, lighting, handwriting, language, or small text? Can preprocessing improve field accuracy? | Baselines: raw image at one resolution. Variables: crop, resize, deskew, contrast, prompt, schema, model. | Field-level accuracy, character error rate, rejection rate, confidence/error calibration, robustness matrix, labelled image fixture set. |
| Agent trajectory reliability | Does a guarded workflow outperform an unconstrained agent on the same task as tool count and task length increase? | Baselines: direct prompt and unguarded loop. Variables: step cap, validation, retries, model size, workflow/agent choice. | Task success, per-step success, end-to-end reliability, step distribution, unnecessary calls, cost, failure trace viewer. |
| Prompt-injection defense evaluation | Which defense layers reduce successful instruction hijacking, and what false positives do they create? | Baseline: naive RAG prompt. Variables: delimiters, instruction hierarchy, input filtering, output validation, tool permissions, human gate. | Attack success rate, benign-task pass rate, leakage rate, false-positive rate, blast-radius analysis, red-team corpus and report. |
| Quality–cost–latency model routing | Can a router send routine questions to a small/local model and hard questions to a stronger model while preserving quality? | Baseline: always use the strongest API model. Variables: routing features, confidence threshold, model pair, caching, output cap. | Quality, cost/query, p50/p95 latency, escalation rate, worst-case failures, routing policy and simulation notebook. |
| Local versus API model under constraints | For a bounded college task, when does a quantized local model become preferable to an API model? | Baselines: API model and a smaller local model. Variables: quantization, context length, language, prompt, hardware. | Accuracy/faithfulness, tokens/sec, TTFT, RAM, energy proxy, privacy exposure, cost at 100/10k users, deployment decision. |
| Evaluation-set quality and judge bias | How much do conclusions change when the evaluator is biased, the test set is contaminated, or the test questions are written by different groups? | Baselines: exact/contains scorer and human labels. Variables: LLM judge, position swap, question author, difficulty, language. | Human–judge agreement, position bias, inter-rater agreement, score intervals, contamination audit, evaluation methodology paper. |
A final-year team should submit all of the following:
| Section | What students should write |
|---|---|
| Abstract | Problem, method, comparison, main number, limitation. |
| Introduction | User/problem context and why the question matters. |
| Related work | 5–10 relevant papers or systems, not a list of buzzwords. |
| Method | Data pipeline, architecture, variables, and evaluation protocol. |
| Experiments | Baseline, ablations, metrics, repeated runs, and resource budget. |
| Results | Tables and plots with the failures visible, not only the best number. |
| Error analysis | Why the system failed and which component was responsible. |
| Ethics and limitations | Privacy, fairness, security, generalization, and non-goals. |
| Reproducibility | Repository, environment, commands, and data statement. |
For most final-year teams, Level B or C is the right ambition. Level D can be excellent, but only when the dataset and evaluation are genuinely strong.
Do not begin with autonomous research agents, multi-agent swarms, Kubernetes troubleshooting, GitHub issue-to-PR automation, distributed training, full RLHF, vision-language pretraining, speculative decoding servers, or a generic chatbot that answers everything. These can become later research directions, but they are poor first college projects because the scope and evaluation boundary are unclear.
| Criterion | Weight |
|---|---|
| Problem clarity and user evidence | 15 |
| Working artifact and reproducibility | 20 |
| Baseline and evaluation quality | 25 |
| Failure analysis and mitigation | 15 |
| Security, privacy, and responsible use | 15 |
| Communication and documentation | 10 |
The best project is not the one with the most agents. It is the one that solves a real, bounded problem and can show a number, a baseline, and an honest limitation.
Use the current course artifacts as your starting point:
For deeper theory, use the external AI Engineering from Scratch curriculum selectively: classical ML evaluation, self-attention, tokenizer construction, LLM application engineering, tool protocols, and observability. Its full 503-lesson curriculum is a long-term roadmap, not a two-day syllabus.