Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#21

Post by gergelycsegzi »

joss82 wrote: post #14
gorgmah wrote: post #6

I worked recently on an internal tool to achieve this kind of things, mostly plugging mistral OCR to gemini to extract structured data from documents. We then perform automated diffs too. There seems to be an insane amount of competition in the "Intelligent Document Processing" market, like for instance parseur, whose founder is often on HN himself. What do you think sets you apart from competition like : 1) Mistral…

Hi, Parseur founder here :D I understand what they are trying to do, but to me it feels like the moment when MongoDB entered the database space, with semi-structured, "flexible" storage format. It has its uses, for prototyping mostly. But in high-volume, production workloads, giving a structure to the data you extract (what Parseur does through defining the Fields in your Mailbox, basically giving your output data a…

Hey, good point about structure for integrated workflows:)

Fully agree, for enterprises we need to guarantee types, flag discrepancies and provide underlying sources so they can integrate it downstream (whether that's Databricks, n8n etc.)

Here is our documentation for working with a fixed JSON schema: https://docs.parsewise.ai/api#schema-driven-extract-convenie...

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#22

Post by gergelycsegzi »

mauryaudayan wrote: post #12

llamaparse also do it, what is different here?

Similar to my other comment, we assume that llamaparse and others can provide the individual page OCR. But once you have that the way that you can integrate it into your workflows often requires additional complexity around combining results from different sources. Here is a deeper dive I wrote on the complexities of building extraction pipelines: https://www.parsewise.ai/doc-processing-pipelines

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#24

Post by gergelycsegzi »

vinaigrette wrote: post #23

This looks great for digital humanities, specifically archival work. Would love to try it.

Fully agree, that's why we quite like the Databricks OfficeQA benchmark.. it made us experts on historical US treasuries haha Some screenshots in here: https://www.parsewise.ai/officeqa-sota

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#27

Post by vinaigrette »

gergelycsegzi wrote: post #24
vinaigrette wrote: post #23

This looks great for digital humanities, specifically archival work. Would love to try it.

Fully agree, that's why we quite like the Databricks OfficeQA benchmark.. it made us experts on historical US treasuries haha Some screenshots in here: https://www.parsewise.ai/officeqa-sota

I'm surprised at the low rate every model manages considering the (apparent) ease of the benchmarked document. Can your pipeline produce ground truth as a byproduct ? How do you think open-weight ocr models compare to the one showcased ? I've had good results with glm-ocr on complex documents (complex by their handwriting, pretty easy layouts).

What I like about your solution is the traceability of the information. A scruffy pipeline I used was gemini-flash 3.0 to pdf to notebook-lm (really amateurish work i know), but it yielded tremendeous time gains to extract info from documents (that could be borderline impossible to read for me). However, to trace back the info was obviously very tedious. But from my experience, notebooklm can now manage ocr/htr without a third party. I wonder how competitive your solution might be compared to messy workflows that work -- albeit with efforts -- but let's the researcher be "in contact" with the material.

What I really want is obviously an easy to setup local rag system, with the (very) light model that goes with it ... sweet dream.

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#28

Post by Johnny_Bonk »

dang wrote: post #20
Johnny_Bonk wrote: post #8

Earlier quoted context omitted.

[flagged]

A launch post is not a place to attack other users personally. Neither is any other HN thread for that matter, so please don't do it here. https://news.ycombinator.com/newsguidelines.html

Noted — and I did wish the founder success. I have no personal ill will towards them. But what I'd ask HN to consider is this: our world, and the technology we introduce into it, isn't apolitical or free of normative stakes and real, harmful implications for people. Treating where you've worked and what technology you've stewarded into being as an ethically neutral fact isn't neutral at all. What concerns me is that there's an increasing firewall against calling out things that ACTUALLLY harm people — while an objection gets reframed as a personal attack on someone willingly able to propagate problematic things. But this seems to be where the corporate tech world is moving as it cozies up to the authoritarians.

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#29

Post by capevace »

I built a similar tool some time ago called Struktur (https://struktur.sh).

It’s much more limited in scope but fully open source and highly customisable. In fact it’s made for people to build their own pipelines on top of, providing the scaffolding needed to do so in a reliable way.

During development I’ve found it to be hard to truly generalise agent/llm-based data extraction, especially around the unlimited number of input types without task specific instructions (many files of the same kind, single large files, mixed kinds, bad quality files, docx/pdf/png/… the list goes on). Users sadly wanna upload all of these, and developers want a „one size fits all“ solution.

I am interested in how your solution deals with this. I came up with a strategy based approach so every task can be customised if needed, but I’d be delighted to see a technical writeup of how you deal with this endless variety of input + extraction task combos! :)

Re: Launch HN: Parsewise (YC P25) – Reason Across Documents with an API

#30

Post by whinvik »

Document parsing is top of my mind lately because in some of the areas we work on the bottleneck is starting to become being able to query documents the same way one queries an api.

I keep thinking the most obvious analogue is we need some way to represent documents the same way we can represent structured data in parquet. Parquet allows easy range bases queries and there is so much tooling built around Arrow.

But for documents I keep hitting a wall to figure out what the right abstractions are. Parquet allows filterable metadata. But what such metadata is there for documents. Then there is the arbitrrariness of chunking, vectorization.

If we could just do this in a 2 step process where every document to process can be represented in a parquet like data format then I think we will atleast have the semblance of a solution.

Post reply on HN