The final presentation shows what the team achieved, how the work was done, and what evidence supports the conclusions, as a clear technical argument rather than a diary.
It should let the audience answer:
What problem was addressed?
Why does it matter?
What was built or investigated?
What data and methods were used?
What experiments were run?
What results were achieved?
What did the team learn?
What remains unresolved?
The final presentation is not a chronological diary; it is a clear technical argument supported by evidence.
The final presentation is a complete, standalone package. It must cover the entire project end to end, including everything already shown at the proposal and midterm, now revised and improved based on the feedback received. How the work unfolded week to week does not matter and should not be recounted; what is assessed is the best, most complete version of the project as it stands at the end. Re-present earlier material in its improved form rather than assuming the audience remembers it or treating it as already done.
What the final must deliver
Seven parts, each with what to present, the requirements, and what to avoid.
1
Final Project Definition
What to present
Give a concise, refined description of the motivating use case, the problem statement, the inputs and outputs, the target users, the main system or research objective, and the final scope. Review the chosen data, models, pipeline, and metrics.
Requirements
Use the final definition, not the proposal wording. The audience should understand the project within the first few minutes.
Avoid
spending too long on background
presenting outdated proposal goals
introducing technical details before the problem
vague statements like "we wanted to improve AI"
2
Project Achievements and Contributions
What to present
State clearly what the team completed. Possible achievements:
a new dataset
a complete processing pipeline
a trained or fine-tuned model
a comparison of several models
a new evaluation protocol
improved performance
a deployed prototype
a new integration
technical insights from experiments
identified limitations in existing methods
Requirements
Separate completed achievements from future work, and give evidence for each claim.
Example. Contribution: a domain-specific dataset of 4,000 labeled samples. Evidence: labeling protocol, inter-annotator agreement, sample distribution, and repository link.
Avoid
listing activities instead of achievements
claiming code volume as an achievement
describing API usage as novelty
presenting incomplete components as finished
overstating minor improvements
3
Methodology
What to present
Explain what was done:
data collection or generation
labeling
preprocessing
data splitting
model selection
training
fine-tuning
prompt development
hyperparameter tuning
evaluation
error analysis
system integration
Requirements
Make it detailed enough for another team to reproduce, and justify the key choices:
Why this model?
Why this data split?
Why these metrics?
Which alternatives were tested?
How were parameters selected?
How was overfitting prevented?
How was data leakage prevented?
The project must include at least one trained or fine-tuned model, not only zero-shot or few-shot prompting.
Avoid
showing code instead of explaining methodology
listing tools without their role
omitting failed experiments
changing evaluation conditions between models
presenting undocumented manual decisions
4
Experimental Results
What to present
Present results in clear tables, graphs, and examples:
baseline results
the main model's results
alternative models
ablation studies where relevant
per-class or per-scenario analysis
quality, latency, or cost measurements
error analysis
Requirements
Compare all methods on the same dataset, test split, metrics, and comparable conditions. Clearly mark the best result, the baseline, the main proposed solution, and statistical variation across runs. Every graph and table needs a title, readable labels, axis names, units, legends, meaningful precision, and a clear caption.
Avoid
screenshots of raw notebook output
unreadable tables
graphs with no axis labels
comparing numbers from different conditions
showing only the best experiment
qualitative examples with no quantitative results
5
Interpretation and Error Analysis
What to present
Explain what the results mean:
why the best method won
where it still fails
which classes or scenarios are hard
whether improvements are practically meaningful
whether results support the original hypothesis
which assumptions were wrong
Requirements
Connect results to the project goals; do not just read the table. Explain likely causes from data characteristics, model architecture, training procedure, domain complexity, label quality, or system constraints.
Avoid
treating correlation as causation
calling every improvement significant
blaming all errors on insufficient data
ignoring unexpected or negative results
drawing conclusions the experiments do not support
6
Conclusion and Future Work
What to present
Answer:
Was the objective achieved?
Which results are strongest?
What did the team learn?
What would you do differently?
What limitations remain?
What should be explored next?
Requirements
Base the conclusion on the presented results, and make future work specific.
Weak: "Use more data and improve the model." Strong: "Collect at least 500 examples from the two underrepresented classes and evaluate class-balanced fine-tuning using macro-F1."
Avoid
introducing new results in the conclusion
repeating the whole presentation
unsupported claims
presenting every unfinished task as future research
7
Demonstrating Project Effort
What to present
Show the work behind the results:
reviewing previous work
cleaning and validating data
comparing multiple models
tuning parameters
debugging the pipeline
analyzing errors
redesigning weak components
rerunning controlled experiments
improving reproducibility
Requirements
Demonstrate effort through technical evidence, not hours worked. Show multiple cycles of implementation, evaluation, error analysis, improvement, and reevaluation.
Avoid
using lines of code as evidence
emphasizing interface design over technical work
presenting repeated API calls as experimentation
confusing implementation difficulty with technical depth
Let the results speak visually
The final talk stands on evidence. Show the comparison that proves the contribution, qualitative success and failure cases, and an honest error analysis, each as a captioned figure.
Make the evidence concrete: sample data (images or text), how the data was generated, the model steps, real model inputs and outputs, and several clear error cases.
Sample data (images or text)
Image, chest X-ray 224×224 · label: pneumonia
"App crashes when I upload a PDF over 10 MB."
Text, support ticket → label: bug
How the data is generated or transformed
"Great pizza, fast delivery."→"gr8 pizza, delivery was not fast"
raw input→preprocess→tokenize / embed→model→post-process→output
Model input and output
"The wifi keeps dropping every few minutes."→{ label: network, conf: 0.92 }
"Summarize this clinical note: ..."→"Intermittent chest pain over two days ..."
input image→2 boxes: car 0.94, pedestrian 0.81
Model errors, with the likely cause
Predicted spam, true not spam: the model over-weighted a marketing phrase inside a quoted reply.
Detected 1 car, missed 1 in heavy rain: low SNR washed out the edges.
Generated a dosage not in the source note: retrieval returned an irrelevant passage.
Submission checklist
This is a quick final check, not a replacement for the full guide. Read the complete requirements above first, then use these ten items to confirm the major pieces are in place before you submit.
The final project definition is concise and clear within the first few minutes.
Achievements are separated from future work, each with evidence.
The methodology is detailed enough to reproduce, with justified choices.
At least three models are compared, including a trained or fine-tuned one and zero/few-shot variants.
All methods are compared on the same data, split, metrics, and conditions.
Results are in clear, captioned tables and graphs (best, baseline, and variation marked).
Interpretation connects results to the goals and explains likely causes.
Error analysis with representative failure cases is included.
Conclusions are supported by the results, and future work is specific.
Effort is shown through multiple implement, evaluate, and improve cycles.
