They use the OCR + structured data extraction in this example, but I'm thinking you could extrapolate this to any scenario where you are extracting some data (from a table, markdown file, OCRed doc), and then use a decision model to perform a fast on-the-fly review/validation.
My masters thesis used a similar approach a couple of years ago, we finetuned a BERT model to categorize natural language questions as either ambigous or non-ambigous in context of the database schema and which queries where plausible candidates to the question. It worked really well, I suppose JEV is orders of magnitude more powerful. There's going to be many applications of good decision models.
The example flags a '10 tablets' dose as a possible erroneous extraction, when the text says exactly that. So it is a false positive.
Furthermore, even if your goal was to catch logical errors rather than extraction errors, you are better off using programmatic checks on the extracted value and having a dedicated error handling path including additional full LLM calls, rather than decision model.
I agree that Jev is pretty cool but example is pretty bad, there is lot more that can be done with it, particularly in unstructured data processing pipeline. One big problem I see is just figuring out if there is new training point is to be found in the data, because with stream of data coming in its waste of resource to process everything
7 comments
[ 0.89 ms ] story [ 35.1 ms ] threadThe example flags a '10 tablets' dose as a possible erroneous extraction, when the text says exactly that. So it is a false positive.
Furthermore, even if your goal was to catch logical errors rather than extraction errors, you are better off using programmatic checks on the extracted value and having a dedicated error handling path including additional full LLM calls, rather than decision model.