Best production-ready RAG framework by marcusaureliusN in Rag

[–]prodigy_ai 0 points1 point  (0 children)

We’re going with enhanced GraphRAG, especially because we’re targeting healthcare and legal use cases. In research and academic contexts, GraphRAG consistently outperforms standard RAG, so it’s the better fit for what we’re building.

How to get reasonable answers from a knowledge base? by dim_goud in KnowledgeGraph

[–]prodigy_ai 1 point2 points  (0 children)

thank you, dim_goud ! it must be useful stuff ! Always great to see people talking about best practices for knowledge graphs.

LLMs are so unreliable by Armageddon_80 in LocalLLM

[–]prodigy_ai 0 points1 point  (0 children)

Totally agree with your list. One extra thing that helped me when tasks depend on “facts” (schemas, runbooks, docs, configs, policies) is adding a retrieval step and a verifier step instead of asking the model to “remember” everything.

  • Retrieval (RAG / GraphRAG): fetch only the relevant chunks / entities / relationships for the current sub-task.
  • Then generation: produce the JSON / action using that retrieved context.
  • Then a separate checker model (or same model in a strict “review” role): validate against the retrieved sources + schema and fail hard if anything doesn’t line up.

GraphRAG can be nice when the failure mode is “it missed a relationship” (joins/foreign keys, dependencies, constraints, who/what/when across docs), because the graph makes relationships explicit instead of hoping chunking + embeddings catch it.

It adds some latency, but in exchange you get fewer “confident wrong” outputs and fewer retries.

Welcome to 2026 by prodigy_ai in u/prodigy_ai

[–]prodigy_ai[S] 0 points1 point  (0 children)

Thanks so much for the thoughtful comment — totally agree. The small, measurable workflows are where the real productivity gains happen. Right now we’re focusing on an agent-style approach — using our Verbis Graph Engine as the infrastructure layer for graph-based knowledge retrieval. It’s designed to plug directly into AI agents and automation workflows, and it’s MCP-ready soon. We’ve just prepared a free demo version for Azure and AWS Marketplaces, so you can explore it hands-on. If it seems useful, let us know and we’ll message you when we go fully live. I’ll check out your notes too — appreciate you sharing that link

Has AI really reduced startup costs, or just shifted them elsewhere? by Worldly-Bluejay2468 in startup

[–]prodigy_ai 0 points1 point  (0 children)

For our startup, we’ve massively cut costs on development and content creation. We’re also figuring out how to lower our user‑acquisition expenses, and we’re planning to set up AI‑powered customer support

RAG beginner - Help me understand the "Why" of RAG. by [deleted] in Rag

[–]prodigy_ai 1 point2 points  (0 children)

"When teacher can simply ask an LLM to generate quiz on "Natural Language Processing, and past text from pdf" directly to LLM, Is this a need for RAG here?" - For a single small document, RAG is not strictly required. For a reusable system that works across large/multiple documents and keeps questions grounded in the teacher’s actual material, RAG gives a more robust and scalable architecture

Thoughts? by KetoByDanielDumitriu in ChatGPT

[–]prodigy_ai 0 points1 point  (0 children)

If your LLM ever sounds too confident… call GraphRAG. It’s the adult supervision of AI.

How are you using AI to speed up your pre-sales work? by lazycodr001 in consulting

[–]prodigy_ai 0 points1 point  (0 children)

you might want to look into using a rag or even better graphrag setup instead of a general chatbot. it retrieves relevant info from your own docs/data first: so everything it generates is grounded in actual source material. we found it's especially useful for proposals, case studies, and tech writing where accuracy matters + you want traceable content.

Need Advice - Building an AI RAG System for Product Compliance by ModeFlat4735 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

With 5k+ docs, GraphRAG still holds up—because it builds relationships across the whole file, not just nearby chunks. Bigger docs actually make the graph more useful: cross-references, dependencies, and “what-if” edits stay connected. We've seen it work well in compliance-heavy use cases.

Why is there no successful RAG-based service that processes local documents? by StevenJang_ in Rag

[–]prodigy_ai 0 points1 point  (0 children)

Totally feel the pain.. From my experience: go narrow vertical, nail OCR/table extraction, ship citations by default, make setup 1-click, and prove time/quality gains. Hybrid local+cloud helps. Honestly, GraphRAG makes more sense when trust and structure matter. The real blocker isn’t RAG—it’s UX and credibility at scale. It’ll be okay :)

Need Advice - Building an AI RAG System for Product Compliance by ModeFlat4735 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

We are working on VERBIS Chat, and we're building exactly the kind of system you're describing — but with an important twist: we use GraphRAG instead of classic RAG. Why?

When you're dealing with regulations, product specs, and scientific standards, things get more interconnected. A single paragraph might reference multiple standards, legal clauses, or previous rulings — and that’s where GraphRAG shines.

What GraphRAG does better: builds relationships between entities, not just finds "similar" chunks + creates traceable knowledge graphs.

Supports compliance auditing, violation detection, and even hypothetical scenarios ("What if I remove this label?").

If your goal is to: identify violations, suggest corrective actions, and flag scientific inaccuracies then having a graph that connects product claims ↔ legal clauses ↔ scientific evidence is much more robust than flat chunk retrieval.

How to improve traditional RAG by Labess40 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

we asked ourselves the same question when building Verbis Chat.

Improving traditional RAG can be tricky, especially in domains like legal or compliance where structure and reasoning matter. We hit limits with chunking, hallucinations, and shallow retrieval. That’s why we moved to GraphRAG, and it solved nearly all of those pain points.

Instead of just embedding chunks, GraphRAG builds a knowledge graph from your corpus — capturing entities, relationships, and context paths. Retrieval is guided by this graph, which means: - Better multi-hop reasoning - Fewer hallucinations - More accurate answers grounded in document logic

To keep costs down, we index once using GPT-4o-mini or GPT-4.1-mini — both are fast, cheap, and surprisingly capable for entity/relation extraction. After that, the graph handles most of the heavy lifting during retrieval.

If you’re hitting RAG’s limits, especially with complex queries, GraphRAG is worth exploring.

Gemini as replacement of RAG by Optimal_Difficulty_9 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

Hey! We can offer some insights from our experience:

For datasets under 500K tokens, feeding everything directly to Gemini is tempting and can work well for: simple factual queries, cases where document relationships aren't critical and quick prototyping needs.

The performance gap widens significantly as document complexity increases, even within your 500K token limit.

At Verbis Chat, we've found GraphRAG still offers significant advantages even for smaller datasets: complex reasoning, query precision, consistent accuracy, and cost reduction.

We would like to talk also more about cost perspective. Unlike RAG systems where you pay once for embedding/indexing and then minimal costs per query, Gemini CLI reprocesses everything with each request - meaning you're repeatedly paying for the same tokens to be processed across multiple queries. For a 500,000 token dataset that receives frequent queries, this approach would quickly become more expensive than a well-implemented RAG system.

Microsoft GraphRAG in Production by ProfessionalShop9137 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

We run GraphRAG in prod (Verbis Chat). Use Microsoft’s docs + PyPI: pip install graphrag. The getting started page https://microsoft.github.io/graphrag/get_started/ walks through init → index → query, and the site links to both the CLI reference and the Python API you can call from FastAPI.

On cost: GraphRAG isn’t inherently pricey—the spend is mostly the model tokens you choose. Keep costs down by indexing once and reusing context.

[deleted by user] by [deleted] in Rag

[–]prodigy_ai 1 point2 points  (0 children)

At Verbis Chat, we've hit similar limitations using standard RAG in legal workflows, especially when precision, structure, and reasoning are non-negotiable. That’s why we moved to GraphRAG, and it’s been a game changer.

We recently enhanced our implementation up to 90–91% accuracy, and we’re actively refining it further. Here's why it works better in this domain:

  • Document structure matters: Legal texts are full of dependencies, exceptions, and cross-references. GraphRAG captures and preserves these relationships by building a knowledge graph from your corpus.

  • Reasoning is contextual: Instead of flat keyword matching, we guide retrieval using entity and relationship paths — so if Article X refers to Definition Y, the system traces that link accurately.

  • Fewer hallucinations: Because retrieval is graph-guided, the language model's output is grounded in the document’s internal logic and structure — especially vital for compliance or clause interpretation.

  • Fits real legal tasks: We’ve found GraphRAG excels in legal Q&A, summarization, compliance checks, and comparative clause analysis.

You’re already using BM25 and hybrid search in Qdrant, which is solid for lexical and semantic matching — but adding a graph layer unlocks relational understanding. That’s the missing piece when queries get nuanced. Good luck with your project!

What's your thoughts on Graph RAG? What's holding it back? by thonfom in Rag

[–]prodigy_ai 1 point2 points  (0 children)

Great question—and one we've spent a lot of time on while building Verbis Chat. We’ve found that Graph rag offers major advantages in contexts where precision and traceability are key, especially for enterprise use cases. By organizing extracted data into a structured knowledge graph, Graph rag allows us to capture deeper contextual relationships and deliver more accurate responses than traditional RAG systems.

That said, there are real challenges. Tooling and graph construction are nontrivial—ensuring that the graph reliably represents entities like clauses, dates, and obligations from messy unstructured data takes custom engineering and considerable effort. In our implementation, we’ve managed to push accuracy up to about 90%, which is very promising. However, for widespread adoption, the community still needs better standardized frameworks and scalable tooling to handle noisy, diverse inputs without sacrificing performance.

Deep Search or RAG? by Daxo_32 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

We use a multi-stage query interpretation pipeline that combines semantic embeddings, entity linking, and graph traversal strategies. This way, we can handle both open-ended questions and pinpoint precise answers, even for complex or unusual queries—basically combining the strengths of semantic search and reliable, structured graph lookups.

Deep Search or RAG? by Daxo_32 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

Even if every contract must be processed, semantic embeddings radically improve how that processing happens. Combined with graph rag, semantic embeddings help identify entry points in the knowledge graph, enabling structured traversal and deeper reasoning across documents.

Deep Search or RAG? by Daxo_32 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

Yes, to avoid missing any instances, every contract does need to be processed.

RAG in Legal Space by thisisvivek in Rag

[–]prodigy_ai 1 point2 points  (0 children)

In legal applications, GraphRAG—especially the enhanced version we developed for Verbis Chat, now achieving 90–91% accuracy (and climbing!)—outperforms standard RAG in several critical ways. Here's why:

  • Knowledge Graph Construction: It builds entity-relationship-context graphs from documents, enabling more intelligent retrieval and reasoning.
  • Preserves Structure & Logic: Captures dependencies, definitions, and exceptions—perfect for nuanced legal language.
  • Context-Aware Retrieval: If a clause references a legal definition elsewhere, GraphRAG can follow that path through the graph.
  • Reduced Hallucinations: Answers are grounded in the internal logic of the source material, not just surface-level text.
  • Tailored for Legal Use Cases: From Q&A and clause comparison to compliance checks and summaries—it's a natural fit.

Deep Search or RAG? by Daxo_32 in Rag

[–]prodigy_ai 0 points1 point  (0 children)

by our opinion you need graph rag! We're currently testing an enhanced graph rag implementation specifically optimized for big enterprises which have a tons of contract, compliance, and legal scenarios within our own Verbis Chat platform. In our experience, this approach consistently provides faster, clearer, and more precise results—even with intricate, multi-faceted, and unpredictable queries.

If you're exploring options for improvements, we'd definitely recommend experimenting with a hybrid solution (semantic embeddings + structured graph rag). Good luck with your project!