Graduation projects in AI that impress the panel

The examining panel saw forty projects this year, and thirty of them were "an app that calls a language model API".

Calling an API is not a project, and they know it. What distinguishes you is not the model you used but the question you asked.

Four properties of a project that lands#

A problem the examiner recognises. A concrete local problem beats a general one translated from a foreign article.

Data you collected yourself. A small Arabic dataset you built is worth more than a large model somebody else trained. It is also the scarcest thing in the field.

Honest evaluation. A project that says "it failed in these cases" beats one claiming "97% accuracy" with no detail. Panels know everything fails sometimes, and a project reporting no failures did not test.

Stated limits. Saying "this is not suitable for that" increases their confidence rather than reducing it.

An idea bank, rooted here#

A dialect test set. Two hundred sentences in your dialect with translations and intended meaning, then test three models against it. The output is both a paper and a tool other people use.

A bias auditor for generated output. Generate images for a range of professions and measure representation. The methodology is simple and the findings are publishable. Background in why AI draws the Arab world wrong.

A grounded assistant for a local institution. A municipality, a faculty, a charity: a system that answers from their documents and refuses what is not in them. The serious part is the evaluation, not the build. Foundations in what is RAG.

Measuring the Arabic token tax. How many tokens does an Arabic sentence consume against its English translation across different models? A simple question with a real financial consequence. Background in token economics.

A local visual archive. Document an architectural style or a craft in your region and build a captioned image set from it. Its value compounds over time.

The questions that sink projects#

Prepare for these specifically, because they recur in every panel:

• "What if the user meant something your system did not understand?" A good answer describes a safe failure path.
• "How do you know it is correct?" Do not say "I tried it". Say what the test set was, how many cases, and the pass rate.
• "What happens at ten times the users?" Answer in cost, not in technology.
• "Where is the data stored and who can reach it?" Especially if your project touches people.
• "What does your project not do?" The easiest question and the one students fumble most.

In closing#

What distinguishes you is not the model you used but the question you asked, the data you gathered, and the failure you admitted. All three are free and available only to you.

Try this today: write down one problem in your own surroundings that your examiners recognise and nobody has solved. That is a better start than any idea list.

Common questions#

What makes an AI graduation project stand out?

A local problem the examiner recognises, data you collected yourself, honest evaluation that reports failures, and stated limits. Calling a ready-made model API is not a project.

Where is the real gap to fill?

Arabic evaluation data. Good test sets are extremely scarce, and building even a small one contributes more than training another model.

Which questions sink projects in the viva?

How do you know it is correct, what happens when the system misreads a user, where the data is stored and who can access it, and what your project does not do.

Can I use real data about people?

Not without consent and anonymisation. Even in a student project this breaches research ethics, and your paper must state how you stripped identifiers.