启动 HN：Parsewise (YC P25) – 使用 API 进行跨文档推理
58 评论
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.
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.
100% the really hard challenge is that the intermediate representation (ie the parquet equivalent) will be dependent on the given use case. So what we do with the platform is have the users configure the intermediate layer that serves most of their queries, and if they need to extend it we will suggest it for them. For example for the demo on the grounded reasoning benchmark I referred to, here is what the intermediate layer looks like on top of which the agents can more efficiently query: https://demo.parsewise.ai/projects/39bee9d8-d722-4b23-8894-e...
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! :)
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! :)
I'll need to check it out!
We had the same observation in that the possible space is almost endless, and for example even for the same file type there may be different kind of processing required (e.g. an excel can be database style, vs small narrative heavy, or both).
We have baked in some ground processing rules for different kinds of documents, and we do allow custom instructions on how to deal with specific cases (e.g. translations, particular format layouts). The best write-up I have at the moment is https://www.parsewise.ai/doc-processing-pipelines but we're working on something that goes into more detail:)
We had the same observation in that the possible space is almost endless, and for example even for the same file type there may be different kind of processing required (e.g. an excel can be database style, vs small narrative heavy, or both).
We have baked in some ground processing rules for different kinds of documents, and we do allow custom instructions on how to deal with specific cases (e.g. translations, particular format layouts). The best write-up I have at the moment is https://www.parsewise.ai/doc-processing-pipelines but we're working on something that goes into more detail:)
How portable are your agent definitions? If I build one for insurance documents, how much work is needed to adapt it to a completely different domain like legal contracts or healthcare?
In practice we find that each domain (and even each organisation) ends up having highly customized definitions.
At first, fairly generic templated definitions sort of work, but what we've seen is that over time data comes up that is out of distribution, and there was no explicit instruction on how to deal with it. In such cases we tend to flag this and offer suggestions to the users on how they can improve the specificity of agents.
Another structure we have seen play out is having a manager review ratings and feedback comments from their team and updating the definitions accordingly over time (where we offer them the capability to see results of before and after side -by-side for all existing data as well, so they are more confident in the change before committing).
The amount of work is dependent on how good the initial definitions are and how complex the use case is (and how much it evolves - new data sources etc). A bit of an unsatisfying answer but it can be anywhere between a few hours one off or a couple of minutes per day on an ongoing basis.
At first, fairly generic templated definitions sort of work, but what we've seen is that over time data comes up that is out of distribution, and there was no explicit instruction on how to deal with it. In such cases we tend to flag this and offer suggestions to the users on how they can improve the specificity of agents.
Another structure we have seen play out is having a manager review ratings and feedback comments from their team and updating the definitions accordingly over time (where we offer them the capability to see results of before and after side -by-side for all existing data as well, so they are more confident in the change before committing).
The amount of work is dependent on how good the initial definitions are and how complex the use case is (and how much it evolves - new data sources etc). A bit of an unsatisfying answer but it can be anywhere between a few hours one off or a couple of minutes per day on an ongoing basis.
Does this also extract semantic relationships and data dependencies between fields?
In the past I'd built an internal tool that transforms insurance PDFs to structured data. I wanted to extract explicit data dependencies between fields to perform validation.
Insurance forms can sometimes have 30-40 pages and they can have fields on page 40 that depend on fields on page 4 with a few nested if conditions. Would Parsewise be able to extract those relationships?
If yes, how do you do it for large documents?
In the past I'd built an internal tool that transforms insurance PDFs to structured data. I wanted to extract explicit data dependencies between fields to perform validation.
Insurance forms can sometimes have 30-40 pages and they can have fields on page 40 that depend on fields on page 4 with a few nested if conditions. Would Parsewise be able to extract those relationships?
If yes, how do you do it for large documents?
Yes, we do it by having multiple stages to the pipeline. First we would extract the independent data points (from say both page 4 and 40) and a second pass step establishes relationship (we call this resolution).
On the scale aspect, because we go in multiple passes, we break the scope into small enough pieces and then build it back up in a later step. Iirc the largest document I've seen a customer use was over 1k pages.
There are more complex data dependency scenarios where we find that the data that's extracted and combined (e.g. from page 4 and 40), needs to then be further transformed in different ways (e.g. having an evaluation and a clarification outcome at the end). To make these be aligned in value we are soon releasing a feature for what we call derived agents.
On the scale aspect, because we go in multiple passes, we break the scope into small enough pieces and then build it back up in a later step. Iirc the largest document I've seen a customer use was over 1k pages.
There are more complex data dependency scenarios where we find that the data that's extracted and combined (e.g. from page 4 and 40), needs to then be further transformed in different ways (e.g. having an evaluation and a clarification outcome at the end). To make these be aligned in value we are soon releasing a feature for what we call derived agents.
1. Incredible! Can I make an unsolicited ask? If you had industry specific templates for standardized PDFs it would be easier for me to send Parsewise to the insurance companies I'd worked for. Something similar to https://www.useanvil.com/forms/?type=pdf-templates but with your clean, semantic data model.
2. Can I ask how? When I was building something like this, I realized there's an element of burning tokens for correctness. Meaning, splitting things into small units and small processes, each using a separate LLM output to be later combined. For a 1k page document, what kind of token usage do you see?
2. Can I ask how? When I was building something like this, I realized there's an element of burning tokens for correctness. Meaning, splitting things into small units and small processes, each using a separate LLM output to be later combined. For a 1k page document, what kind of token usage do you see?
Re 1 - that is a very kind offer! Our current public template library is very limited, so let me come back to you on this.
2. We see exactly the same thing. There is a trade-off in correctness vs token burning. However, some tokens (models) are cheaper and faster than others, so the small pieces can benefit from that. The token usage is also surprisingly variable, because it depends on the information density of the document and also on the information density of the question (e.g. is it a single needle in a haystack or are we analyzing the entire haystack from 10 perspectives). So the parsing for 1k pages may be on the order of millions of tokens, while a series of queries (extractions) on top of it could be 1-2 orders of magnitude more.
2. We see exactly the same thing. There is a trade-off in correctness vs token burning. However, some tokens (models) are cheaper and faster than others, so the small pieces can benefit from that. The token usage is also surprisingly variable, because it depends on the information density of the document and also on the information density of the question (e.g. is it a single needle in a haystack or are we analyzing the entire haystack from 10 perspectives). So the parsing for 1k pages may be on the order of millions of tokens, while a series of queries (extractions) on top of it could be 1-2 orders of magnitude more.
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.
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.
We were also surprised at first. The reason the models don't do so well is that they need to find information across 90k pages. When they are pointed to the right location they tend to do much better. And with these treasury documents grepping / keyword searching is almost impossible because everything appears thousands of times.
And thank you, we also love the traceability, it's one of the aspects that we have prioritized. Models will never be perfect so rather than building the best model harness we went for the best human harness haha.
Tbh it's been a while since I've looked at notebooklm so I expect it would have gotten better over time. One thing where I found it lacking in the past was the structure we could get out (which gives the traceability) - for example a deep dive on one the underlying data for this corpus: https://demo.parsewise.ai/projects/39bee9d8-d722-4b23-8894-e...
And yes, we're really excited whenever new open weights models come out that push quality, price, latency. We're finding that throughput is a big obstacle so I'm looking forward to more of this running locally, but it will be a while..
And thank you, we also love the traceability, it's one of the aspects that we have prioritized. Models will never be perfect so rather than building the best model harness we went for the best human harness haha.
Tbh it's been a while since I've looked at notebooklm so I expect it would have gotten better over time. One thing where I found it lacking in the past was the structure we could get out (which gives the traceability) - for example a deep dive on one the underlying data for this corpus: https://demo.parsewise.ai/projects/39bee9d8-d722-4b23-8894-e...
And yes, we're really excited whenever new open weights models come out that push quality, price, latency. We're finding that throughput is a big obstacle so I'm looking forward to more of this running locally, but it will be a while..
"With experience and support from" is a nice landing trick!
How do you extract and relate to each other the facts from the documents that require comprehension and not simple similarity matching using common embeddings models?
How do you extract and relate to each other the facts from the documents that require comprehension and not simple similarity matching using common embeddings models?
Haha thanks, the reader can try and guess which is which;)
We actually don't use embeddings or vector similarity, since those tend not to work well in specialist domains (e.g. for the OfficeQA benchmark where we have 90k pages talking about US treasury numbers, they would be mostly mapped to a very small embedding space because it's all the same topic, with small variations across years, expense categories etc.).
We use LLMs for the extraction and comparison as well, and we route between different models depending on the complexity of the comprehension of the given step required (and by this I mean routing between our pipeline steps; we currently do not dynamically try to judge individual cases for complexity like OpenRouter Fusion).
We actually don't use embeddings or vector similarity, since those tend not to work well in specialist domains (e.g. for the OfficeQA benchmark where we have 90k pages talking about US treasury numbers, they would be mostly mapped to a very small embedding space because it's all the same topic, with small variations across years, expense categories etc.).
We use LLMs for the extraction and comparison as well, and we route between different models depending on the complexity of the comprehension of the given step required (and by this I mean routing between our pipeline steps; we currently do not dynamically try to judge individual cases for complexity like OpenRouter Fusion).
Might be interested in orthogonal reading - "The Textual Warehouse" (ISBN-10: 163462954X) by data warehouse pioneer Bill Inmon. He is and always has been ahead of his time with his thinking!
This does indeed look really interesting. We have deterministic validations (and some deterministic excel transformations) but using more deterministic transformations for text based on traditional NLP would be a nice complement.
Interesting product! Do you think it would work for e-discovery? I have around 120GB of emails, contracts, and the like, and I need to search for data and where certain expressions are referenced.
Potentially, but at that scale cost and latency may actually become an issue, so probably better to consider some sort of indexing or keyword searching.
clickhouse?
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 document AI : depending on the model, it looks way cheaper than yours, OCR model pricing ranges from 0.001 to 0.004 EUR / page and they have structured output wired in the OCR API if needed (things then get fed to one of their LLMs) + EU-based and GDPR ready 2) parseur / rossum / docsumo / nanonets (which is YC 2017) ?
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 document AI : depending on the model, it looks way cheaper than yours, OCR model pricing ranges from 0.001 to 0.004 EUR / page and they have structured output wired in the OCR API if needed (things then get fed to one of their LLMs) + EU-based and GDPR ready 2) parseur / rossum / docsumo / nanonets (which is YC 2017) ?
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 schema) adds a ton of value, and the larger the dataset, the truer it is.
Usually, you start by defining where you want your data to go, and which structure it should have, before working backwards from here and starting to extract the data. This is the key to automating your document workflow.
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 schema) adds a ton of value, and the larger the dataset, the truer it is.
Usually, you start by defining where you want your data to go, and which structure it should have, before working backwards from here and starting to extract the data. This is the key to automating your document workflow.
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...
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...
Great question!
1. We are working with the assumption that OCR is (or soon will be) solved at super low prices.
So if we have the extracted data, what can we do with it? Where we see Parsewise making a difference is for use cases that span across documents. I.e. if you are extracting the same 5 fields from every invoice, there are lots of solutions as you listed (+ reducto etc). However, once you have a set of documents (e.g. an entire mortgage application package) and you are trying to get a structured response out, then your option is either an LLM API (if things fit into context and you are okay with limited citations), or building a pipeline with LLMs. I posted it in another comment but an example of trawling through 90k pages is here: https://www.parsewise.ai/officeqa-sota
2. While we rely on LLMs, the outcomes will be non-deterministic, so the bottleneck is and will remain the human verification (that is for somewhat complex use cases). The architecture that we have built is optimizing for the human reviewer to provide as granular values and citations as possible. This is either through our platform, or API clients.
1. We are working with the assumption that OCR is (or soon will be) solved at super low prices.
So if we have the extracted data, what can we do with it? Where we see Parsewise making a difference is for use cases that span across documents. I.e. if you are extracting the same 5 fields from every invoice, there are lots of solutions as you listed (+ reducto etc). However, once you have a set of documents (e.g. an entire mortgage application package) and you are trying to get a structured response out, then your option is either an LLM API (if things fit into context and you are okay with limited citations), or building a pipeline with LLMs. I posted it in another comment but an example of trawling through 90k pages is here: https://www.parsewise.ai/officeqa-sota
2. While we rely on LLMs, the outcomes will be non-deterministic, so the bottleneck is and will remain the human verification (that is for somewhat complex use cases). The architecture that we have built is optimizing for the human reviewer to provide as granular values and citations as possible. This is either through our platform, or API clients.
What about deterministic parsing?
Basically using templates to extract info from recurring doc structures ??
Basically using templates to extract info from recurring doc structures ??
I am seeing my client using things like this heavily (not exactly this). Also, what I would call "business awareness" is declining.
I can see why, it's tempting to go for full automation. The reason we go for fine grained sourcing is so that people can build their awareness quickly. Plus many of our customers work in regulated industries where full automation is prohibited.
Hey ! Is this kind of like structured output over a large scale document corpora ?
Hey, that's exactly it!
I say this with a lot of love: The vibecoded applications in your demo reek of AI slop design.
This isn't a critique of your product. It's just that the a beige-orange theme, the pill components, and the left-border highlight give me that visceral reaction as reading a paragraph littered with em dashes and "not X but Y." It makes me take you less seriously.
Cool demo otherwise.
This isn't a critique of your product. It's just that the a beige-orange theme, the pill components, and the left-border highlight give me that visceral reaction as reading a paragraph littered with em dashes and "not X but Y." It makes me take you less seriously.
Cool demo otherwise.
Haha no appreciate it! That's on me for not calling it out explicitly (was trying to make the video as short as possible), but the demo UIs were literally vibe coded to show the ease of integration https://youtu.be/F1cSuZal03s?si=1H4zTcO-8cosLbVr&t=70
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
Mostly cross-doc reasoning at scale (e.g., 90k-page corpora) as opposed to doc-to-markdown conversions.
Just use claude. Not another wrapper
If Claude is good enough for your use case then for sure. If you need scale, persistent structure and verifiability we can help:)
Ah probably should add a link to our website: https://www.parsewise.ai/api
Added above :)
[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
https://news.ycombinator.com/newsguidelines.html
I do respect your moderation, however I addressed the statement, the choice of words, not the person.
To sarcastically reword someone's statements using fake quotation marks* to depict them as exploitative is at minimum an accusation of insincerity, and the snark adds an additional layer of aggressiveness. You also used "cognitive dissonance" as a trope to basically accuse them of lying. All this is personal and, since it was an attack, crosses into personal attack.
(* also not allowed here btw: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...)
(* also not allowed here btw: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...)
I learnt a lot at Palantir, though always worked in commercial so no ties to security state (for the better or worse).
(Also side-note, we are working towards enabling frontier performance with smaller open models that allows our customers to protect their data. https://www.parsewise.ai/officeqa-sota )
And I do get genuine joy from helping our users, so love it is:)
And I do get genuine joy from helping our users, so love it is:)
[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
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.
Sure, and HN hosts many threads where people debate these points. We're not against that and often as not agree with them.
But this is a startup launch thread about something unrelated, and hounding someone about an ex-employer is a tenuous ground for bringing such material up. It's the sort of thing this guideline (from https://news.ycombinator.com/newsguidelines.html) asks people not to do, even apart from the personal aspect:
"Eschew flamebait. Avoid generic tangents."
More about that here in case helpful: https://news.ycombinator.com/item?id=48750103
But this is a startup launch thread about something unrelated, and hounding someone about an ex-employer is a tenuous ground for bringing such material up. It's the sort of thing this guideline (from https://news.ycombinator.com/newsguidelines.html) asks people not to do, even apart from the personal aspect:
"Eschew flamebait. Avoid generic tangents."
More about that here in case helpful: https://news.ycombinator.com/item?id=48750103
yes i do agree, thank you
Do you ask this to all HNers who have worked at Meta, Google, Microsoft and Amazon - the latter three who Palantir relies on to even exist?
I.e. half of HN?
I.e. half of HN?
no but we're all implicated including myself
Planning to serve good things for sure, and appreciate your note.
Ofc I didn't agree with everything Palantir was doing (also to the extent that we even knew about them at the time). I was working on vaccine distribution and cancer research as well, so definitely felt like helping.
想象一下给 Claude 一堆文件并要求 CSV 或 JSON 输出。如果您尝试过这一点，您就会知道系统限制（文件数量、输入类型、成本、延迟），而且也知道无法快速验证结果所面临的人类挑战。我们解决这两个问题。
我们帮助技术团队简化他们的非结构化数据 ETL，并让业务专家循环进行定义和即时验证。
以下是包含一些用例的视频：https://www.youtube.com/watch?v=dbRllnnh47w
用一个来找我们的人的话来解析：
“我需要从保单 PDF、已转录的电话、电子邮件等中提取信息。我并不是在寻找能够逐个数据点、逐页提取数据到结构化、定义良好的模式中的东西，而是寻找更具有代理性的东西，能够理解信息可能跨文档，并且应该推理出要提取的内容。”
我们基于在复杂数据转换和数据分析/综合方面十年的经验（和痛苦）创办了公司。 Greg 正在 Palantir 构建经典 ETL 并实施 AI 工作流程。在贝恩，马克斯在金融领域进行了高度复杂的数据分析，与我们的许多客户类似。
Parsewise 的工作原理是接收一桶数据（例如数百或数千个 pdf、excel 等），并输出符合模式的数据，其中每个值都可以追溯到桶中多个文档的字级引用。我们为API客户提供在自己的应用程序中展示血统的方法，或者他们可以使用我们的平台进行内部操作。
在数据处理的核心，我们有自我改进的代理定义。它们定义了可接受的来源、解决或组合值的逻辑以及向最终用户强调不确定性的规则。
底层技术与模型和云无关，可以部署在专用网络中。我们已经看到 Gemini 模型在视觉推理方面的最佳结果，在我们发现的最强大的推理基准（Databricks OfficeQA）上实现了 SOTA（击败 Claude Fable）。
值得注意的是，我们更多地关注“人体安全带”而不是模型安全带，倾向于我们在吸收中看到的实际摩擦，这是围绕可验证性的。这意味着优化信任结果所需的时间和点击次数。
我们使用 vLLM 进行解析，然后使用小模型进行高效的大规模穷举搜索。与 RAG 不同，我们不采样；相反，我们详尽地查找给定查询的所有相关值。我们使用更大的模型来围绕解决方案进行决策并向用户标记不一致的情况。
这种详尽和明确的价值来源是我们平台所独有的，它超出了许多现有提供商所涵盖的数据解析的第一步。
我们非常欢迎构建者和修补者尝试 Parsewise 来解决复杂的文档挑战。关于如何扩展产品并使其变得更好，我们有很多想法，但我们非常感谢社区的反馈和想法！