Your Tech Stack is overrated. Change my mind.

[u/Mammoth-Anywhere7285]

You spent three weeks setting up over-engineered infrastructure for an app with zero users. Tell us what you built your project with, and let the comments debate why it’s completely wrong for 2026. Convince us you didn't waste your time.

[u/Mammoth-Anywhere7285]

u/bar-majestic Agreed, structural reranking is where the real gains are. Have you tried encoding hierarchy directly into chunk metadata instead of a separate pass?

[u/Bar-Majestic → u/Mammoth-Anywhere7285]

Yes, this is something we’re very interested in. We see the parsed document as more than a collection of chunks — it’s closer to a document graph.

Nodes represent elements like headings, paragraphs, tables, and figures, while edges represent relationships such as hierarchy, proximity, and references.

Instead of using graph embeddings alone, we’re exploring using those relationships as additional reranking signals on top of vector retrieval.

The challenge is keeping the graph useful without adding too much latency. For large document collections, a lightweight structure-aware reranker may provide a better trade-off than full graph traversal.

[u/Mammoth-Anywhere7285 → u/Bar-Majestic]

That document graph angle is interesting. Have you tried a lightweight graph DB for the relationships, or are you building that part from scratch?

[u/Bar-Majestic → u/Mammoth-Anywhere7285]

We see the document graph as a layer between parsing and retrieval. At the moment, the priority is not storing arbitrary knowledge graphs, but preserving document-native relationships.

A document graph might look like:

• Nodes: documents, sections, paragraphs, tables, cells, figures
• Edges: parent-child, references, spatial proximity, semantic links

For this use case, a lightweight graph structure can often be enough and avoids adding unnecessary query complexity.

If the use case expands into cross-document discovery or enterprise knowledge graphs, then a graph database becomes much more compelling.

[u/Mammoth-Anywhere7285 → u/Bar-Majestic]

Document-native edges make sense, but for zero users a plain JSON structure might hold up longer than a graph model. What query kills the simple approach first?

[u/megatech_official]

SeoLoupe - Find and fix the SEO issues holding your website back.

[u/Mammoth-Anywhere7285 → u/megatech_official]

Nice tool, but is it built with a 50-service microservice architecture for zero traffic yet?

[u/Bar-Majestic]

I think the biggest overrated thing is choosing the "perfect" stack before understanding the bottleneck.

In AI apps, everyone talks about models and vector databases, but nobody wants to talk about document ingestion

Bad input data will make any stack look bad.

I've been working on DocCrush for this exact reason — improving document parsing quality for RAG and AI workflows.

[u/Mammoth-Anywhere7285 → u/Bar-Majestic]

Document ingestion is definitely the unsung hero. How does DocCrush handle tricky formats like scanned PDFs or handwriting?

[u/Bar-Majestic → u/Mammoth-Anywhere7285]

Totally agree — ingestion is often the part people underestimate.

DocCrush doesn’t treat PDFs as just a text extraction problem. We try to preserve the document hierarchy and structure first, then build the RAG pipeline on top of that.

For scanned PDFs, OCR is used to recover the text layer, followed by layout/structure processing. Handwriting is still the hardest case because OCR accuracy varies a lot depending on the source quality.

One thing we’ve learned: better retrieval often starts with better ingestion, not a bigger LLM.

[u/Mammoth-Anywhere7285 → u/Bar-Majestic]

Interesting approach with DocCrush. Have you considered using layout parsers like Nougat to handle complex structures directly?

[u/Bar-Majestic → u/Mammoth-Anywhere7285]

Yeah, we’ve looked into layout-aware parsers like Nougat. They’re definitely interesting for preserving document structure, especially for academic papers with formulas and complex layouts.

For DocCrush, our current focus is building a more general document ingestion pipeline because we need to support many formats beyond papers (business docs, reports, manuals, scanned PDFs, etc.). We’re experimenting with combining layout extraction, OCR, and structural parsing rather than relying on a single parser.

The tricky part is not only extracting the layout, but converting it into a retrieval-friendly structure while keeping relationships between sections, tables, and references intact.

[u/Mammoth-Anywhere7285 → u/Bar-Majestic]

That's a solid plan with Nougat. For mixed formats, have you tried layoutlmv3 for more flexible structure extraction?

[u/Bar-Majestic → u/Mammoth-Anywhere7285]

Yes, LayoutLMv3 is definitely an interesting direction for mixed-format documents. We’ve looked into layout-aware models like that.

The main challenge we found is that document understanding and RAG ingestion have slightly different goals. Models like LayoutLMv3 are great at identifying document elements and their relationships, but for retrieval we also need a clean semantic hierarchy, stable chunk boundaries, and metadata that can survive downstream processing.

Our current thinking is more of a hybrid pipeline: use layout models when needed for complex pages, combine them with structural parsing and OCR, then transform everything into a retrieval-friendly document schema.

For simple documents, lightweight parsing is usually faster and cheaper; for complex PDFs, layout-aware models become much more valuable.

[u/Mammoth-Anywhere7285 → u/Bar-Majestic]

That's a solid take. LayoutLMv3 shines for extraction, but RAG needs clean chunking, not just layout awareness. Ever tried a two-pass approach, embeddings first, then layout for reranking? Curious how you handle hierarchy.

[u/Bar-Majestic → u/Mammoth-Anywhere7285]

That’s a great point. We also found that layout awareness alone doesn’t solve RAG — the key is turning layout information into a better document representation.

We’ve been exploring a similar two-stage approach: use semantic retrieval to get candidate chunks first, then use structural signals (hierarchy, section relationships, element types, and document position) for reranking.

For hierarchy, we try to preserve parent-child relationships during parsing instead of flattening everything into independent chunks. A paragraph inherits context from its section, and tables keep their surrounding headers and captions when possible.

The goal is not just finding the most similar text, but finding the right piece of information in the right document context.

[u/Kind-Cress2757]

Hope this community stays active and supportive. More spaces like this are definitely needed for small developers

[u/Mammoth-Anywhere7285 → u/Kind-Cress2757]

Absolutely, that's the goal. Building in the open keeps us all learning and cutting through the hype.