Why I Want to Build This

A lot of useful information is easy to save and surprisingly hard to find again. A project note ends up in one folder, an explanation sits inside a long report, and the answer to a question is buried in documentation I have already read. Finding it again can take longer than the task that needed it. That is the kind of problem I want to explore with an AI chatbot. Could I ask a question in everyday language, get a useful explanation, and see where the answer came from? Could it help me return to an old project without having to read everything from the beginning? As an Electrical & Electronic Engineer, I also see this as a chance to build beyond the areas I already know. A chatbot brings together software, data, interface design, and testing. It gives me a practical reason to learn those skills: there is a real task to support and a result I can check.

From Enclosure Design to a Physical Prototype

The project also has a physical side: a small device with its own display and enclosure. That adds another reason to keep working on it. Alongside the chatbot software, there are practical questions about how the parts fit together, how easy the screen is to read, and how the device feels to use.

The enclosure model shows how those features fit into one compact shape. Moving from a model to a printed part gives me something tangible to inspect and improve, bringing the project closer to the hardware work I enjoy.

The prototype photo shows the interface displaying a response inside the printed enclosure. It gives the project a concrete starting point for further testing: how clearly it presents an answer, how it handles longer replies, and what needs to change to make everyday use easier. The document-search ideas below are a direction I would like to explore as the project develops.

What the Chatbot Would Do

An AI chatbot lets someone interact with software through conversation. A rule-based chatbot follows predefined paths, while one built around a large language model can generate responses to more varied questions and follow-up messages. That flexibility is useful, but it also means an answer can sound convincing even when it is wrong. For this project, I would start with a small collection of project notes or technical documents. The first goal would be simple: help someone find and understand information in those documents. For example, I could ask, "Why was this component selected?" or "What still needs testing?" The chatbot should point to the relevant source, explain what it says, and make it clear when the documents do not contain an answer. That would give me a manageable starting point and a way to judge whether it actually helps.

What I Gain by Starting

The first benefit is learning how the pieces fit together. Using a chatbot is one thing; building one means deciding what information it receives, how it handles a question, and what the user sees when something goes wrong. Even a small version would give me practice connecting an interface to a model, preparing documents, handling responses, and checking the output. It would also force me to think about questions that are easy to overlook in a demo: Is the answer supported? Is it understandable? Was asking the chatbot faster than opening the document myself? There is a portfolio benefit too. A working project, with its decisions and limitations documented, would give me something concrete to discuss. I could show how I defined the problem, what I tried, and how I checked whether the result was useful. Starting small makes that learning achievable. I do not need a chatbot that can answer everything. A first version that handles a narrow set of questions well would already give me something worth improving.

Why Keep Working on It?

The strongest reason to continue would be the questions the first version struggles with. A missing answer might reveal a gap in the source material. A confusing response might show that the explanation needs work. A slow response might make an otherwise useful tool frustrating to use. Each of those problems gives the next stage a purpose. I could collect examples, make a change, and check whether the same questions get better answers. Over time, that would build experience in maintaining a system, as well as creating one. If the chatbot becomes reliable enough for its intended tasks, the practical benefit could grow with the document collection. It could help me revisit older work, explain a project to someone new, or reduce the time spent answering repeated questions. Those are benefits I would want to measure through use, rather than assume from the start. Continuing would also let me reuse what I learn. Document search, clear interfaces, error handling, and evaluation are useful skills across many software and engineering projects.

What Needs Care

Accuracy would be the main challenge. Retrieving relevant document passages before generating an answer, an approach called retrieval-augmented generation (RAG), could help ground the response. It would still need checking: finding a relevant passage does not guarantee that the chatbot interprets it correctly. I would want source references and a clear way for the chatbot to say it cannot answer. For engineering questions, it should help locate and explain information; calculations and design decisions would still need verification. Privacy, response time, and running cost would also shape the project. I would begin with material suitable for the chosen service and keep the scope small enough to understand how it behaves before adding more data or features.

Where I Would Take It Next

With a physical prototype to build on, my next software milestone would be connecting the conversation interface to a small document collection, with source references in the answers. I would check it against questions with known answers, along with questions the documents cannot answer. After that, I would let actual use guide the next steps. Better document search, clearer explanations, and useful follow-up questions would matter more than adding features simply because they are possible. What makes this project worth pursuing is the chance to learn while solving a problem I can recognise in my own work. Starting would turn the idea into something I can test. Continuing would give me the opportunity to make it dependable enough to return to when I need it.