Vinny LaRocca: Thanks for joining, everyone. So we got a couple of questions in here, Dan. One of them right out of the gate: How do we deal with scanned-in documents?
Dan Leszkowicz: Yeah, great question. So, I’ll answer, and then I’ll show you a little bit, actually. So, I’m going to go back to one of the talking points from one of the first slides where I described that kind of society of models that are doing different things.
And the reason for that is not all documents are created equal. Some of them start out as digital, like my, you know, magic wand invoice. Some of them start out as a paper copy or something that was scanned and then emailed, or something like that. And by employing that society of models, we can call on the right model for the right task. And one of the models might be, first, an OCR model that turns that formerly hard copy into something digital that we can then make sense of with other models.
And so, I’ll actually pop back into the demo for a sec. And I’ve got one that is exactly that. So, this is—you can see it’s a pretty old invoice from an open source data set. So, it is over—it’s like 26 years old. And you can tell from the quality here, not great scan quality. Everything’s kind of a little fuzzy. There’s even some handwriting over it. And what I did is I ran it through the platform, and it did a great job of pulling out the fields. And what I also found interesting is—this is not directly related to the question—this is actually a relatively complicated table in the sense that there’s a little bit of nesting going on here.
So, if you look at the line item table, there’s sort of this like header that applies to everything below. And then there’s this almost like a sub-header for each individual line item.
And the platform was smart enough to correlate those two. So, it pulled out the header as well as the very specific line item information for each of the descriptions, and did it for both.
Now, the other thing that just—this happens to give me an opportunity to speak to—is I sort of passed over this earlier, but on the right-hand side you’re seeing confidence intervals for everything that we’re pulling out of the document. Everything I showed on the last document came back as green, high. Almost everything here is green, high, but you are seeing one that came back as yellow for medium.
And so, this goes back to my talking point from earlier about that set of verification models that are coming over the top and saying thumbs up, thumbs down, does this look good.
What they’re actually doing is attaching a confidence score. And so, we can use this to flag to the end user when we need to put a human in the loop, and they need to put a human eye on this document and say, “Document, does this match the field that we pulled out?”
So, this does a couple of things, right? It makes it easier for them to do that validation. It also ensures that anything that is just getting straight-through processed—pushed right along to, you know, the ERP system, AP system, what have you—we’re very certain that it is okay to pass along and doesn’t need further verification.
Which kind of goes back to one of those points that I made earlier. If you were just dealing with a single model, a single IDP tool that didn’t have that suite of models, you either need to trust everything implicitly and just pass it along, or you need to validate everything manually before you can pass it along. In which case, why do automation? So, we feel like this is the right approach, where we can flag things we’re not certain and give a human the opportunity to intervene.
Vinny LaRocca: Yeah, and I think there’s, you know, there’s certainly some scenarios like a two-way, three-way matching scenario where somebody may say, “I’m going to match it anyway,” so the confidence threshold may not be as important. But those types of use cases where confidence is, you know, not as important are really few and far between.
And I think in most cases with IDP, not having the ability to flag something to bring it to a human and not having these confidence thresholds is just simply going to be a showstopper for most people. And we’re all sort of used to—if you’ve used IDP in the past with traditional machine learning—we’re all used to seeing confidence thresholds and being able to leverage that to flag to human in the loop as exceptions. And as far as I can tell, currently this is the only LLM-based platform that has this capability.
Dan Leszkowicz: Awesome.
Vinny LaRocca: Alright. So, one other question, Dan. So, how does somebody get started with Pienso?
Dan Leszkowicz: Yeah, certainly. So let me pop back over to slides for a sec for that one.
So we have a—you just made a great point about—we’re one of the few platforms that offers that kind of verification step and that reliability. We’re also one of the few platforms—only platform I know of—that has what I think is a pretty novel deployment methodology, a real evaluation deployment methodology.
So this is typically how we like to engage with customers. It typically starts off with, you know, pre-sales conversations, planning conversations. We’re trying to scope: What are you trying to do? What’s your volume of documents, the complexity of the documents? What are you trying to pull out? Etc.
It really only takes a couple of weeks, and then from there, we start on what I’ll call a 6-week pilot, and there’s a little bit of nuance to how this pilot works.
Once we’ve scoped everything out in the planning process, at the beginning of the 6-week pilot—let’s assume we have an understanding of the types of documents and an understanding of the, you know, dozen or so fields that we want to be able to pull out of those documents—at the beginning of that pilot, we collectively stack hands on what is the accuracy and the STP that you need to get by the end of that 6-week pilot to make it worthwhile, right? For it to be a successful project.
And we guarantee that STP. By the end of that pilot—that 6-week process—is an iterative process where we’re working together. We’re handling the prompt engineering, the flow engineering, with feedback from your team, your subject matter experts who are in the weeds, so to speak, in terms of what is what’s important on an invoice or on a contract or what have you.
The important thing is, by the end of that 6-week process, we have hit STP, right? That’s what we guarantee. And from there, we can move right to production.
And if we don’t hit STP, you have a money-back guarantee. We can part as friends if you want. We can continue tweaking the prompts and so on.
But the important point is, it’s sort of a try-before-you-buy methodology. The reason being is, if you think back to that first slide with all the squiggly lines—there are a lot of horror stories out there from folks who have gone into an IDP project kind of oriented around accuracy and thought it was going to be really successful really easily. And more and more organizations are finding out that’s not the case.
And so this is our way of offering kind of an experiential evaluation process where you can be certain that you’re going to get the STP that makes it worthwhile before you have to, you know, write a check and move to production.
Vinny LaRocca: Awesome. Alright, I think that’s all the time we have, so thanks for joining, everybody. Appreciate it.
Dan Leszkowicz: Thanks, everyone. Thank you, Vinny.
