Two philosophies, one pipeline
The field of natural language processing has two long-running traditions. The first is rule-based and statistical: build explicit systems from human-curated knowledge — dictionaries, grammatical rules, frequency statistics — and apply them mechanically to text. The second is learned: train a neural network on enough text that it develops an implicit model of language and can generalize to novel inputs.
For most of the 2010s, these traditions were positioned as competing. In practice, they are complementary, and the best-performing systems often use both. Rereflect's analysis pipeline is an example of this: it uses rule-based and statistical methods (VADER, TF-IDF, keyword matching) where they are sufficient, and calls a language model where they are not.
Understanding the tradeoffs helps you configure Rereflect appropriately for your situation — and helps you interpret results honestly rather than expecting either approach to be perfect.
Where rule-based approaches win
Rule-based methods have properties that matter for practical deployments:
- Speed — VADER can score thousands of items per second. A TF-IDF classifier is similarly fast. No waiting for API latency or model inference time.
- Cost — rule-based methods run in-process with no per-call charges. There is no token budget to manage and no API key required.
- Privacy — text never leaves your infrastructure. For teams with data residency requirements or strict policies about sending customer content to third-party services, rule-based analysis is the only compliant option.
- Determinism — the same input always produces the same output. You can reason about the system's behavior and debug it when something looks wrong.
- No dependency — VADER and TF-IDF work without a configured model, API key, or internet connection. They run regardless of LLM availability.
For straightforward sentiment classification on English informal text, VADER performs surprisingly well. For identifying that a feedback item is about "export" because it contains the word "export," keyword matching is perfectly adequate. Not every feedback item needs a language model.
Where LLMs win
Language models bring capabilities that rule-based systems cannot replicate:
- Contextual understanding — an LLM can recognize that "it keeps crashing on me" is negative and about reliability, even though "crashing" is not in the pain-point keyword list.
- Paraphrase and synonym handling — "sluggish," "slow," "takes forever," and "laggy" all map to the same underlying complaint. A language model handles these naturally; a keyword list requires each to be enumerated.
- Sarcasm and irony — "great, another outage" is negative despite containing the word "great." LLMs handle this far better than lexicon-based systems.
- Multi-language text — a capable multilingual model can classify feedback in French, Spanish, or Japanese without separate per-language rule sets.
- Complex multi-topic items — a single feedback item that touches billing, UX, and a specific bug can be correctly tagged to multiple categories by a model that reads it holistically.
These advantages come at a cost: latency (LLM calls take seconds, not milliseconds), token spend (each item costs money if you are using a hosted API), and a dependency on a model being configured and available.
How Rereflect combines them
Rereflect uses a tiered approach. VADER runs on every item, always, for sentiment scoring — it is fast, free, and good enough for the majority of English feedback. TF-IDF clustering runs across the corpus periodically to surface thematic groups. Keyword matching makes an initial categorization pass on each new item.
The LLM layer runs on items where the keyword pass is ambiguous or where deeper categorization is needed — pain point extraction, feature request classification, urgency reasoning. If an LLM is configured, these steps use it. If not, the keyword-only results are used as a fallback.
This means you can run a fully useful version of Rereflect with no LLM configured at all. You get sentiment, basic categorization, and topic clustering. When you add an LLM — whether a hosted API or a local model via Ollama — the categorization quality improves, particularly on ambiguous and nuanced items.
Choosing the right configuration for your situation
The right balance depends on your constraints:
- No LLM, fully offline — use Rereflect with just VADER and keyword matching. Good for small volumes, strict privacy requirements, or teams that want to start immediately without any AI configuration.
- Local LLM via Ollama — add a local model for better categorization while keeping data on your own infrastructure. Appropriate for teams with a GPU or a server with enough memory, and strong privacy or data residency requirements.
- Hosted API with your own key — use OpenAI, Anthropic, or another provider for the highest categorization quality. You pay the provider per token. Best for teams where accuracy is the priority and data residency is not a blocker.
None of these configurations is universally correct. The point of Rereflect's design is that you can start with no model, see whether the results are useful, and add a model later if you want better accuracy — without changing anything else about how the system works.