mohammadalfaiz.blog

Botzy began as an exploration of a simple question: how can small businesses provide useful, always-available customer support without the cost and complexity of building a custom AI system from scratch? While large organizations can invest heavily in AI infrastructure, many smaller businesses struggle to make generative AI practical, reliable, and affordable. I built Botzy to address that gap by creating a platform that allows businesses to upload their own documents and deploy an AI assistant grounded in their specific knowledge base.

As the project evolved, I discovered that building an AI product involves much more than connecting a language model to a website. The core challenge became designing a system that could consistently retrieve relevant information, provide accurate responses, and remain cost-effective to operate. This required evaluating different retrieval architectures, embedding models, vector databases, and prompting strategies. Throughout development, I iterated through multiple versions of the retrieval pipeline, balancing response quality, infrastructure complexity, and operational cost.

One concept from AI Leaders that strongly influenced my thinking is that successful AI systems are not judged solely by model capability, but by their ability to create reliable and measurable impact. Rather than maximizing model sophistication, I focused on building a system that could operate predictably within real-world constraints. This led me to treat evaluation, retrieval quality, and system reliability as first-class engineering problems. The result is a platform that reflects how I think about AI: not as a standalone model, but as a complete system requiring thoughtful architecture, continuous evaluation, and practical tradeoff decisions.

Architecture & Design Decisions

The central architecture problem in Botzy was not simply generating responses, but making sure those responses were grounded in the business’s own documents. To do that, I designed the system around a retrieval pipeline that connects uploaded content, embeddings, vector search, and a language model response layer.

• Retrieval-augmented generation: I prioritized grounding the assistant in uploaded business documents rather than relying only on the model’s general knowledge, which helped reduce hallucinations and make responses more relevant.
• Vector database selection: I used ChromaDB as the retrieval layer because it allowed me to build and test locally with lower infrastructure complexity while still supporting semantic search over uploaded documents.
• Embedding model choice: I experimented with different embedding approaches and prioritized a balance between semantic quality, cost, and deployment simplicity rather than only choosing the most powerful model.
• Prompt engineering and guardrails: I designed prompts to keep the assistant focused on retrieved context and avoid unsupported answers, treating reliability as an engineering requirement rather than an afterthought.

These decisions reflect the main lesson I learned while building Botzy: an AI system is only useful if it can be operated reliably under real constraints. The architecture is not just about using an LLM; it is about controlling data flow, managing tradeoffs, and designing the system so that its outputs remain grounded, measurable, and useful.

Evaluation & Iteration

Building the initial retrieval pipeline was only the first step. The more important question was whether the system was actually returning useful information from uploaded documents. Rather than evaluating the assistant solely on whether it produced fluent responses, I focused on whether the retrieved context was relevant to the user’s question and whether the final answer remained grounded in the source material. During testing, I repeatedly uploaded different document sets and manually evaluated the quality of responses, looking for missing context, incorrect retrievals, and instances where the model attempted to answer beyond the available information.

One of the most significant iterations involved the retrieval stack itself. Over the course of development, I experimented with multiple embedding models, retrieval configurations, and vector database approaches. Early versions often returned incomplete context or missed relevant sections of documents. To improve retrieval quality, I adjusted chunking strategies, retrieval parameters, and embedding approaches while continuously testing the system against real questions. These iterations helped improve the consistency and relevance of retrieved information without significantly increasing operational complexity.

This process reinforced an important principle from AI Leaders: successful AI systems require continuous evaluation rather than a one-time implementation. Building the model integration was relatively straightforward; understanding its failure modes and improving system performance was the more valuable engineering challenge. The goal was not simply to deploy an AI assistant, but to create a system that could reliably deliver useful, grounded responses while balancing quality, efficiency, and maintainability.