How to incorporate AI into a thesis.

The honest starting question is whether your research has a prediction, classification, or pattern-finding problem inside it. If it does, machine learning is a legitimate method. If it does not, adding a model is decoration, and a panel will find it.

A useful test: can you finish this sentence without hand-waving? “Given [these inputs that are realistically available], predict or categorize [this outcome], which currently requires [expert judgment / slow measurement / guesswork].” If you can, you have a real problem. If the sentence keeps drifting into vagueness, the problem is not yet a machine learning problem.

The alternative worth considering seriously is that AI belongs in your thesis as a tool rather than as the contribution. Using a model to process your data, code your interviews, or analyze your images is a methodological choice you disclose in your methods chapter. That is different from the model being the thing you are studying, and it is a much smaller undertaking.

This is the step that decides whether the project is possible, and the step most students reach too late. Every machine learning method needs examples where the answer is already known, because that is what the model learns from.

Concretely: you need records where both the inputs and the outcome were recorded. If you want to predict something that nobody ever wrote down, you do not have a dataset, and no amount of modeling skill fixes that. This is the single most common reason a project has to be rescoped.

On quantity, the honest answer is that it depends on how many input variables you have. A few hundred rows is a workable floor for a simple tabular problem with a handful of inputs. The requirement rises as you add variables, and image work needs substantially more labeled examples than most students expect. Text and image projects are usually where an overambitious scope shows up.

If your data is currently in scanned PDFs, inconsistent spreadsheets, or handwritten survey forms, that is normal. It is work, not a blocker. What genuinely blocks a project is having no outcome variable at all, or having one that was recorded so inconsistently that it cannot be trusted.

Students consistently reach for the most sophisticated architecture available, on the assumption that a bigger model makes a better thesis. On the dataset sizes typical of academic research, the opposite is usually true: large models overfit small data, and a panel of researchers will recognize it.

The defensible move is to start with a simple baseline and only add complexity when it earns its place. That gives you the answer to the question you will definitely be asked, which is why did you choose this method. “Because I compared it against a simpler one and it performed measurably better on held-out data” is a complete answer. “Because neural networks are state of the art” is not.

Whatever you choose, you have to be able to explain what it does in plain language. Not the mathematics necessarily, but the idea: what the model is learning, what its inputs and outputs are, and where it is likely to be wrong.

This is where a lot of otherwise good projects lose marks. There are a small number of mistakes that recur, and every one of them is avoidable.

Reporting accuracy on the same data the model trained on is the most common. It is not a result; it measures memorization. You need a test set the model never saw during training, and the numbers you report come from that.

The second is reporting only overall accuracy. A confusion matrix, with precision and recall per class, tells you and your panel where the model actually fails, which is a far more interesting finding than a single percentage.

The third is scaling or encoding your data before splitting it. If you fit a scaler across the whole dataset and then split, information from your test set has leaked into training, and your reported numbers are inflated. Split first, then fit on the training portion only.

The fourth is time-series data split randomly. If your data has a time order, a random split lets the model learn from the future to predict the past. Split chronologically.

Panels ask a fairly predictable set of questions, and preparing honest answers to them before the defense is most of the work of passing it.

Why this method and not a simpler one. What are the limitations of your model. What would happen if you gave it an input outside the range it was trained on. How much data would you need to do better. What does this model not tell you. Why should anyone trust these numbers.

The best preparation is a working demonstration. A model the panel can put inputs into and see respond is far more convincing than a notebook narrated from a laptop screen, and it changes the tone of the defense from justification to demonstration.

There is a real line between getting technical work built and having your thesis written for you, and it is worth stating plainly.

Commissioning the engineering — data pipeline, model, evaluation, deployment — and then understanding it well enough to explain and defend every decision is ordinary research practice. Research groups hire technical staff and statisticians all the time, and the contribution is disclosed. What is not acceptable is submitting analysis or writing as your own when you cannot account for it, or presenting a model whose choices you cannot explain.

Your institution's rules on acknowledgment are the ones that govern. Ask your adviser what needs to be disclosed and disclose it. Any technical collaborator worth working with will expect you to.