A multimodal RAG pipeline that answers our community’s questions in Discord around the clock, running on RocketRide Cloud.
By Krish Garg and Mithilesh Gaurihar
A few months ago, a new member joined our Discord, installed RocketRide that evening, and got stuck around midnight. They could not find the configuration file they needed, so they asked in the help channel.
By morning, someone on our team had found the right documentation, added a little context, and sent it over. The member was unblocked. A week later, somebody else asked the same question. Then another question arrived while the team was asleep. The answers were usually already written down, but a person still had to find and deliver them.
That was the actual problem. We didn’t need more documentation. We needed a better path between the documentation and the person asking for help.
So we built a retrieval-augmented generation pipeline that could accept our existing material, find useful context for a question, and return an answer in the same Discord channel. We call him Rocket Ralph. The RocketRide portion is 21 components on the canvas: 30 minutes to a working path, longer to a trustworthy one. Our existing Discord bot sends messages to the pipeline through a webhook, so we didn’t have to build another application around it.
If you would rather watch than read, we recorded the build:
What We Wanted
We weren’t trying to build another bot that replies with “Have you checked the FAQ?”
The useful version had to work with the material we already had: written guides, PDFs, screenshots, recorded walkthroughs, and the repositories themselves. It also had to stay inside Discord. Nobody should have to leave the conversation, open a separate support tool, and ask the same question again.
There were two parts to the pipeline. One prepared our knowledge for retrieval. The other handled questions as they arrived.
Turning Messy Material Into Searchable Context
The ingestion flow begins with a Dropper, RocketRide’s file-input node. The Dropper accepts the source material; the downstream nodes decide how to process it.
Documents go through parsing, then chunking with a RecursiveCharacterTextSplitter so the pieces break on natural boundaries instead of mid-sentence. Screenshots and extracted images go through OCR. Audio is transcribed. Video can be separated into audio and representative frames so that spoken explanations and on-screen text are not lost. Each path eventually produces text with enough source information to understand where it came from.
A miniLM embedding model converts those text chunks into vectors, and the pipeline stores them in Qdrant. The practical reason for doing this is simple: the wording in a question rarely matches the wording in a document exactly. Someone may ask about an “authentication problem” while the relevant guide calls it a “login error.” Vector retrieval gives us a way to find likely matches based on similarity rather than relying only on exact keywords.
This step does not train the agent or guarantee that it will find the right document. It creates a searchable index of the material we supplied. That distinction became important later, because retrieval quality is something we can inspect and improve.
What Happens When Someone Asks a Question
When a message arrives from Discord, our bot forwards it to the pipeline’s webhook. The query side then follows a short path:
- The question is embedded using the same miniLM model used during ingestion.
- Qdrant returns the closest matching chunks, filtered by a 0.7 similarity score threshold so marginal matches stay out of the context.
- The question and retrieved context are passed together to a CrewAI agent backed by OpenAI GPT-4.1.
- The answer is trimmed to 1,900 characters, safely under Discord’s message limit, and returned to the channel.
For harder questions, Ralph also has tools that can inspect our GitHub repositories or call an external API. Those tools are optional; retrieval remains the first source of context. If the indexed material does not contain a reliable answer, the agent should say so rather than fill the gap from memory.
The Guardrails
An agent with tools needs limits more than it needs more capabilities, and Ralph’s limits are enforced by the pipeline rather than left to the prompt:
- The GitHub tools are read-only. Ralph can search and read our repositories; he cannot write to them.
- The HTTP tool makes GET requests only, and only against a whitelist of URLs we control.
- Tool calls are rate-limited, so a misbehaving loop cannot hammer an API or drain a quota.
- Ralph cannot claim a search happened without a tool result to show for it. If nothing came back, the answer says so.
- When he cannot answer, or a tool errors in a way he does not recognize, he does not improvise. He mentions the team in the channel so a human can jump in.
- Billing questions are not his to answer. Those get a team mention, every time.
The credentials behind those tools are stored as RocketRide environment variables and injected at runtime. They are not pasted into the .pipe file, which means the pipeline can be shared or versioned without carrying an API key with it.
Inspecting Every Step
The first version did not always retrieve the context we expected. That was useful, because it showed us exactly what we needed from the tooling around the agent.
RocketRide’s Status view shows the active task and its nodes. The Flow view shows the route an input took through the pipeline. The Trace tab exposes the useful debugging details: what Qdrant returned, what context the agent received, which tools it invoked, what each stage produced, and how long the stages took.
That is not the same as reading a model’s private chain of thought. It is something more operationally useful: a record of the inputs, retrieval results, tool activity, and outputs that we can actually act on.
If an answer is weak, we can see whether the problem began with parsing, chunking, retrieval, prompting, or a tool call. Instead of changing the prompt and hoping for the best, we can fix the stage that produced the bad input.
Don’t Take Our Word for It
The first real test worked: the same kind of configuration-file question that started this project came in through Discord, moved through embedding and retrieval, and came back answered, with the right documentation attached and nobody on the team involved. But our word is exactly the kind of evidence this post says you shouldn’t settle for.
So test him yourself. Join our Discord and ask Ralph a real question. Then try to make him make something up: ask about a feature we don’t ship, a configuration option that doesn’t exist, a version that was never released. The guardrails above mean he cannot claim a search he never ran, and his instructions tell him to say when the indexed material doesn’t support an answer. Whether he declines or answers, the Trace shows exactly what was retrieved, what he was given, and what he did with it. We read those traces.
One successful answer does not prove that a support bot is finished. It does prove the path works end to end. The next work is less glamorous and more important: adding representative source material, testing the questions people actually ask, reviewing failed retrievals, and giving the agent a clear way to admit when the context is insufficient.
Why We Run It on Cloud
Building the pipeline was only half the job. A Discord support bot needs a stable endpoint when nobody has the RocketRide canvas open and every developer laptop is closed.
We run the .pipe on RocketRide Cloud so the webhook and pipeline remain available. Cloud also gives the team one place to manage runtime variables and inspect live tasks and traces. The artifact itself stays portable: it is the same .pipe format we can run locally or with the open-source server.
That portability matters. A team with strict data-residency requirements or an existing platform group can self-host the runtime and operate the surrounding services. We use Cloud here because answering Discord questions is the product workflow; maintaining the infrastructure behind that workflow is not.
What We Would Tell Someone Building This
Start with the material you have, not the knowledge base you wish you had. Useful context often lives in screenshots and recordings as well as polished documentation.
Treat retrieval as a component to test, not an oracle. Qdrant returns candidates. The agent still needs clear instructions for using them and for declining questions they do not support.
Finally, demand evidence from the pipeline. You should be able to see what was retrieved, what reached the model, which tools ran, and what came back. Without that record, every incorrect answer becomes guesswork.
The result is not a replacement for the people in our community. It handles the repeated questions whose answers already exist, including the ones that arrive while the team is asleep. That leaves the human conversations for the problems that actually need a human.
Build Your Own
Everything Ralph runs on is available today:
- Build and host your pipeline on RocketRide Cloud
- Rather run it yourself? rocketride-server is open source
- Or build right in your editor with the RocketRide VS Code extension
And if you get stuck, hop into the RocketRide Discord and ask. Yes, Ralph is in there too.
답글 남기기