🖥️Word Vector Search

This is the node that turns "a pile of text" into "the few paragraphs actually relevant to this question" - the retrieval half of RAG (retrieval-augmented generation), packed into one node instead of the usual chain of chunker → embedder → vector store → similarity search you'd wire up by hand in most frameworks. The pack's README calls this out directly as one of its headline capabilities: "word vector RAG... to localize the management of the industry knowledge base." This node is where that actually happens.

How it works

Feed it raw text and a question, and internally it does the standard RAG pipeline in sequence: split the source text into overlapping chunks, embed each chunk into vector space, embed the question the same way, then return the chunks whose vectors sit closest to the question's - the ones most likely to actually contain the answer. What you get back is a compact slab of relevant context to hand your LLM, instead of dumping an entire document into the prompt and hoping the context window and the model's attention both hold up.

The inputs and outputs that matter

• question (default "question") - what you're searching for. This is the query side of the similarity search.
• model_path - the embedding model to use for turning text into vectors. Point it at a local embedding model path or a HuggingFace repo id.
• k (default 5) - how many chunks come back. Raise it if answers seem to be missing relevant context; lower it if you're flooding the prompt with marginal matches.
• chunk_size (default 200) / chunk_overlap (default 50) - how the source text gets split before embedding. Smaller chunks are more precise about what matches but lose surrounding context; the overlap keeps a sentence that straddles a chunk boundary from getting cut in a way that breaks its meaning.
• device (auto/cuda/mps/cpu) - where the embedding model runs.
• Optional file_content - this is where your actual document text goes in. Without it, there's nothing to search over.
• Optional base_path and ebd_model - base_path gives the node somewhere to work from on disk; ebd_model lets you hand in an already-loaded embedding model object from a separate loader upstream instead of having this node load model_path fresh on every run, which matters if you're calling this repeatedly and don't want to pay the model-load cost each time.

One output: ebd_response, the retrieved chunks, ready to drop straight into your LLM's prompt as grounding context.

Installing it

Standard pack install:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt from inside the pack folder using ComfyUI's Python (portable builds: python_embeded\python.exe -m pip install -r requirements.txt), then restart.

Embedding models aren't bundled - model_path needs to point at something real, whether that's a small local sentence-embedding model you've downloaded or a HuggingFace repo id this node can pull on first use.

Common issues & troubleshooting

Results feel irrelevant or thin. Usually a chunking problem before it's a retrieval problem - chunk_size too large buries the relevant sentence in noise; too small and it loses the context needed to actually answer the question. Start near the defaults (200/50) and adjust from there rather than guessing blind.

Slow on every single run. If you're not passing ebd_model, this node reloads the embedding model from model_path fresh each time it runs - fine for a one-off, painful in a loop. Load the embedding model once upstream and pass it in via ebd_model if you're calling this node repeatedly in the same session.

model_path errors out. Same failure mode as any HuggingFace-style loader in this pack - a typo in the path or repo id gives you a load error with no correction hints, and a gated or private repo will fail without credentials this node doesn't have a field for. Double-check the exact path before assuming something's broken.