Simple LLM: Add Document

Simple LLM: Add Document is the write side of the pack's tiny RAG system: it takes a chunk of text, a doc_id, and some metadata, and stores them into a vector store so a later query can use them as context. In practice it's "give a piece of your workflow a label and a home" - the node that turns a string into retrievable knowledge.

Before you get excited about RAG, let's be precise about what "store" means here, because the pack is honest about its ambitions in an unassuming way. A vector store in this suite is a plain dictionary, and the "embedding" it computes for your document is an MD5 hash of the text. That's not a semantic embedding - it's a fingerprint. Nothing here measures similarity, searches by meaning, or ranks by relevance. Add Document's job is to file the text under doc_id with some metadata attached, and that's it. The retrieval side (Simple LLM: RAG Query) then just hands the first few stored documents to the LLM verbatim.

Which is fine, if you know what you're in for. The intended use is small: a style guide, a character sheet, a few reference notes that you want the LLM to "read" before answering. You're not building a knowledge base; you're making a handful of texts available to the model in one workflow. For that, this node is exactly as much machinery as the job needs.

How it works

You feed it an existing VECTOR_STORE (created by the pack's Simple LLM Vector Store node, which is just a named container), the document text, a doc_id (default "doc_1"), and optionally a metadata JSON string (default "{}"). It copies the store, saves the text under the doc_id, computes the MD5 "embedding," parses the metadata (bad JSON silently becomes {}), and returns the updated store. It's pure dictionary surgery - no model calls, no network, instant.

Inputs and output

vector_store (VECTOR_STORE) - the store to add to.
document (multiline STRING) - the text itself.
doc_id (STRING, default "doc_1") - the key it's stored under. Reusing an id overwrites.
metadata (optional STRING, default "{}") - a JSON object for tagging, e.g. {"source": "notes.md", "style": "dark fantasy"}. Currently nothing in the pack uses it for retrieval, so it's bookkeeping.

Output is the VECTOR_STORE, which you pass on to the next Add Document or into a RAG Query. Chain multiple Add Documents off one store to build up your context set.

The gotchas

The metadata is inert. It's stored and echoed, but the pack's query node ignores it. Don't build logic on it.
Order matters more than you think. Because retrieval just takes the first top_k documents in insertion order, the order you add documents is the retrieval ranking. Add your most important reference text last if you want it least likely to be trimmed... no wait - add it first. The query pulls from the front. Get your document order right and "retrieval" works exactly as well as this system can.
No dedup. Adding the same doc_id twice silently overwrites; adding two different ids with the same text stores both. Keep your ids meaningful.

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 with the same URL, restart. No model downloads, no API keys needed for this node itself - the API key lives on the config/agent side when you actually call an LLM. Dependencies are the pack's light set.

The honest take

Calling this "RAG" is generous, and the MD5-fingerprint-as-embedding is the kind of thing that would get a real RAG engineer to raise an eyebrow. But judged as "a way to give my LLM call a few reference documents in a ComfyUI graph," it's perfectly serviceable and refreshingly light. Keep your store small, keep your document order intentional, and it'll do the job without pulling in an embedding model.