Yes, we needed to solve the problem for our other product (https://kili.so). We spent a lot of time getting accuracy up for dense and multi-page invoices. Then realised other teams have this need as well so decided to ship the API.
On the accuracy point, given our work so far we believe we are best in class in terms of accuracy for document extraction. We've also set up a system of evaluations internally that allow us to keep iterating and improving (hence us mentioning that we want to continue working on it).
I can only speak to our experience. Once you get under the hood, you find that this is a hard problem to solve.
There are also a lot of workflows that involve documents in every sector and every function. In other words, the opportunity is massive.
For our product, our customers are either internal engineering teams or folks building products that require document extraction but don’t want to invest time in it.
This is in the problem description of your pitch, and leads me to believe that tile.run has been solving this problem. Is that right?
> Coming Soon:
> - Improved accuracy
Can you expand more?
I have a large need for this sort of tooling, but accuracy is my primary concern.
On the accuracy point, given our work so far we believe we are best in class in terms of accuracy for document extraction. We've also set up a system of evaluations internally that allow us to keep iterating and improving (hence us mentioning that we want to continue working on it).
I can only speak to our experience. Once you get under the hood, you find that this is a hard problem to solve.
There are also a lot of workflows that involve documents in every sector and every function. In other words, the opportunity is massive.
For our product, our customers are either internal engineering teams or folks building products that require document extraction but don’t want to invest time in it.