Simple LLM: RAG Query

Let's get the uncomfortable part out front: Simple LLM: RAG Query is not really doing retrieval-augmented generation in the sense you might be picturing. Real RAG embeds your documents, then retrieves the most semantically relevant chunks for a query. This node takes the first top_k documents in the store, pastes them above your query, and hands you a prompt. That's it. It's a document sandwich, not a search.

Which is fine - if you set expectations correctly. Where this fits is the ComfyUI-native version of "stuff my documents into a prompt and ask a question." You're not building a production knowledge base; you're asking an LLM a question about a handful of notes you shoved into the graph. For that, it works, and it works without any heavyweight embedding stack.

How it works

The Simple LLM RAG chain is three nodes: a Vector Store (which is just a named dict in this pack), Add Document (which stores text under a doc_id with some metadata), and this one. When you run the query:

1. It pulls the documents from the store - specifically the first top_k in insertion order (default 3, max 10).
2. It builds a prompt shaped like:

Based on the following context, answer the query.

Context:
Document 1:
...
Query: your question

Answer:

3. It outputs that as a single rag_prompt STRING, designed to be fed into Simple LLM Run: Prompt.

That last step matters: this node does not call any LLM itself. It produces a string. The actual answer comes from wherever you send that string next - typically SimpleLLMRunPrompt with your agent attached.

Inputs and output

• vector_store (VECTOR_STORE) - the store you've been adding documents to.
• query (multiline STRING) - your question.
• top_k (INT, 1–10, default 3) - how many documents to stuff into the context. Keep it low; LLM context windows are finite and most of these documents will be irrelevant noise.

Output is a single rag_prompt STRING.

Where it lies to you

Two things to keep straight. First, there are no real embeddings. The pack's Add Document node "embeds" each document by storing an MD5 hash of its text - that's a fingerprint, not a vector, and nothing here does similarity search. top_k is just "how many documents, in order added." If you add 10 documents and ask about the last one, you'll only get it if it falls inside top_k.

Second, if the store is empty, the node returns a string like "No documents found in vector store. Original query: ..." rather than erroring. That's a passable failure mode, but don't mistake it for an answer.

Installing it

Part of ComfyUI-NS-Util:

cd ComfyUI/custom_nodes
git clone https://github.com/NakamuraShippo/ComfyUI-NS-Util

or ComfyUI Manager → Install via Git URL, restart. No model downloads; dependencies are the pack's usuals. Remember the pack labels its LLM section "Implementing the tests now," and this RAG subset is the roughest edge of it.

The honest take

If you genuinely need semantic search over a large document set, use a real RAG stack and stop reading. If you want to hand an LLM a couple of reference texts you're already holding in the workflow - a style guide, a character sheet, a notes file - this is a perfectly serviceable, if not very clever, way to do it. Just keep the document count small and remember that "top_k" here means "first k," not "best k."