Load Keyword Searcher

If you want retrieval over your own documents but don't want to pay for embeddings or run a vector database, this is the node for you. It does keyword-based search instead of semantic search - no embedding model, no API call, no vector store. You get something that works locally, for free, immediately, at the cost of being less clever about matching meaning rather than exact words.

This is the free half of a two-node choice this pack gives you for knowledge-base retrieval. The other option, OpenAI Word Vector Search, actually embeds your text and does similarity search - better recall for questions phrased differently than your source text, but it costs an API call (or needs a local Ollama embedding model) every time it runs. Load Keyword Searcher skips all of that: it chunks your text, matches chunks against your question by keyword, and returns the closest hits. For a lot of small, well-defined knowledge bases - FAQs, a glossary, a handful of reference docs - keyword matching is honestly good enough, and it's the sane default to reach for first before you decide you actually need embeddings.

The inputs that matter. question is the query you're searching for - typically wired from user input or the same prompt going to your LLM. file_content is required with no default, meaning it's meant to be piped in from upstream, almost always from Load File Folder or wherever else you're pulling your source text from - this node doesn't read files itself, it only searches text it's handed. k (default 5) controls how many chunks come back; raise it if your LLM keeps missing context it should have had, lower it if you're stuffing too much irrelevant text into the prompt. chunk_size (default 200) and chunk_overlap (default 50) are the classic text-splitting knobs - how big each searchable chunk is, and how much adjacent chunks overlap so you don't lose an answer that happened to fall on a chunk boundary. is_enable is the pack's usual toggle to disable retrieval without pulling the node out of the graph. The single output, relative_info, is a STRING you feed straight into your LLM node's context - the matched chunks, ready to use.

Installing it. This ships as part of the full comfyui_LLM_party pack - no separate install. Get it through ComfyUI Manager (search "comfyui_LLM_party") or cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt from inside the project folder using your ComfyUI Python environment, and restart. Unlike its embedding-based counterpart, this node needs no API key and no external service - it's local, pure-Python text matching - so there's genuinely less to configure and less that can go wrong here than almost anywhere else in this pack.

Troubleshooting. If relative_info comes back empty or unhelpful, the usual cause is a mismatch between how your question is phrased and the wording in your source text - keyword search only finds what's literally there, so if your question uses different words than your documents, raise k first and consider rephrasing before assuming the node is broken. If your source text is long and results feel scattered, try tightening chunk_size so each chunk is more tightly on-topic. And if the whole node pack fails to load rather than just retrieval behaving oddly, that's this project's large bundled requirements.txt hitting a version conflict somewhere unrelated to this specific node - check the ComfyUI console for the real error.