LLM-Zero-to-Hundred: A Multi-Project Teaching Repository, Not a Library

What LLM-Zero-to-Hundred Actually Is

The repository is a container for eight finished projects and two tutorials, not a single codebase. The README lists them as Hidden-Technical-Debt-Behind-AI-Agents, WebGPT, RAG-GPT, WebRAGQuery, LLM Full Finetuning, RAGMaster (LlamaIndex versus Langchain), Open-Source-RAG-GEMMA, and HUMAIN. Two tutorials sit alongside: LLM function calling and vectorization. Each entry links to its own folder on the master branch. Jupyter Notebook is the primary language, which tells you the intended consumption mode: read the cells, run them in order, watch the intermediate output. That matters for who this is for. If you want a pip-installable RAG library, this is the wrong shape of artefact. If you want to see how a RAG pipeline is assembled step by step, with the retrieval, prompt construction and generation stages visible in separate cells, the notebook format is the point. The README also links a YouTube channel for each project, so the repository functions as companion material to video walkthroughs rather than as self-contained documentation.

The Shared Folder Convention and What It Implies

Every project follows the same layout, which the README spells out: a README.md, a HELPER.md for execution notes, a .env for local configuration, a .here marker for the project root, a configs folder holding yml files, a data folder with sample data, a src folder with the source code and a src/utils subfolder for shared modules, and an images folder for UI assets. The README is explicit that this is the general structure and that individual projects may deviate. Two details are worth noting. First, the .here marker means the code locates the project root by file presence rather than by a hardcoded path, so moving a project folder does not break it. Second, the configs folder holding yml files implies configuration is separated from code, and the .env file implies secrets are handled through environment variables. Those are sensible choices for teaching. The cost is that every project carries its own copy of the layout and its own dependency set, so there is no single environment to install. You set up each project you want to run, separately.

The Agent Stack: Docker Compose, VectorDB Bootstrap, Weave Scope

The Hidden-Technical-Debt-Behind-AI-Agents project is the most infrastructure-heavy entry. Its README bullets claim an agentic chatbot built with LangGraph, real databases for what it calls production-style design, a microservice architecture using Docker Compose, automated VectorDB creation inside the container, visual monitoring with Weave Scope, and development best practices. Read those as a list of topics the project demonstrates, because the top-level README does not give the compose file, the service names, or the database choices. That is the trade-off of a teaching repository: the interesting decisions are inside the folder, not in the index. What can be said from the structure is that this project is the one where the configs folder and the Docker Compose file do the real work, and where the .env file likely carries database credentials and model API keys. If you are evaluating this repository for an agent architecture, this is the folder to open first, and the HELPER.md next to it is where the run order should be documented.

HUMAIN and the Multimodal Surface Area

HUMAIN is described as an advanced multimodal, multitask chatbot with a long feature list: ChatGPT-like conversation, RAG in three modes (preprocessed documents, documents the user uploads during the session, and any website the user requests), image generation through a stable diffusion model, image understanding through the LLava model, DuckDuckGo search integration, summarization of websites or documents, text and voice input, and session memory for previous queries. The README states plainly that HUMAIN was built on top of RAG-GPT and WebRAGQuery. That lineage is the useful part. It means the multimodal features are layered onto an existing retrieval core rather than designed from scratch, and the retrieval behaviour you see in HUMAIN should match what those two earlier projects do. The breadth is also the risk. Each capability (diffusion, LLava, search, speech) pulls in its own model weights and dependencies, and the README does not state which of them are optional. Expect the setup cost here to be the highest in the repository.

Open-Source-RAG-GEMMA: The On-Prem Path

This project answers a narrower question than the rest: what does a RAG chatbot look like when nothing leaves your machine. The README says the author took RAG-GPT and converted it into a fully open source chatbot using Google Gemma 7B as the language model and BAAI/bge-large-en as the embedding model, deployed on-prem. Both choices are concrete and checkable, which makes this the most directly reusable entry in the repository. The conversion also tells you what the original RAG-GPT depended on: replacing the generation and embedding components is what makes the pipeline local. The limitation is stated by omission. The README does not give VRAM figures, quantisation settings, or throughput numbers for Gemma 7B, so you cannot size hardware from this material alone. Treat the project as a working reference for wiring an open model into a retrieval pipeline, and measure your own memory footprint before committing to a machine.

RAGMaster: A Comparison Exercise, Not a Benchmark You Can Cite

RAGMaster-LlamaIndex-vs-Langchain compares five RAG techniques drawn from Langchain and Llama-index, tested on 40 questions across five documents, and ships two separate RAG chatbots covering eight techniques from the two frameworks. The design is deliberate: rather than argue about which framework retrieves better, the project builds both and runs the same questions through them. That is a more honest structure than a single-framework tutorial. The caveat is scale. Forty questions over five documents is a small evaluation set, and the README gives no scoring rubric, no judge model, and no result table in the material available here. Use this project to learn how the two frameworks express the same retrieval idea in different APIs, and to get a template for running your own comparison on your own corpus. Do not quote its outcome as evidence that one framework is better in general.

Fine-Tuning, WebGPT, and the Function-Calling Tutorial

The fine-tuning project uses a fictional company called Cubetriangle and walks through processing its raw data, fine-tuning three large language models on that data, and building a chatbot with the best-performing one. The libraries listed are Hugging Face, OpenAI, and Chainlit, which suggests the pipeline spans local training and an API-backed chat interface. That combination is worth noting: fine-tuning happens locally or on rented compute, but the resulting chatbot is served through Chainlit, so the project covers both halves of the workflow. WebGPT is different in kind. It handles questions that require internet searches, and the README says it identifies and executes the most relevant Python functions in response to user queries, with a second part that is cut off in the material available. The function-calling tutorial covers that mechanism directly. If your interest is tool use rather than retrieval, WebGPT plus the tutorial is the pair to read, and the fine-tuning project is the one to read if you have domain data and want to see the training loop end to end.

Licence, Maintenance, and What to Verify Before You Copy Code

The licence is not declared in the material available, and there are no retrieved releases. For a repository whose value is its code, an undeclared licence is the single most important thing to resolve before reusing anything. Without a licence, the default position under copyright is that no rights are granted, so copying notebooks into a product is a decision you make with your own legal advice, not something this review can settle. On maintenance, the last push recorded is 2026-04-29, and the repository is not archived, so it is active. But there are no releases, which means there is no versioned artefact to pin and no changelog to read when something breaks. The practical consequence: if you build on a project folder, record the commit hash yourself, because the repository will move. The second thing to verify is the HELPER.md in each folder. The top-level README summarises features and links videos; the per-project file is where the author says how to actually execute the code, and it is the difference between reading a project and running it.

Editorial conclusion

Adopt this repository as a reading and study reference if you want worked examples of RAG, agent orchestration with LangGraph, and open-source on-prem deployment using Gemma 7B and BAAI/bge-large-en. Do not adopt it as a dependency: there is no package, no release, and no declared licence, so anything you lift into a product needs its own provenance check. Before cloning, open the project folder that matches your goal and read its HELPER.md, because the top-level README only summarises each project and the per-folder file is where execution details live.

Official sources

1. Farzad-R/LLM-Zero-to-Hundred on GitHub
2. Issues
3. README