HN user

kietay

24 karma
Posts1
Comments26
View on HN

One example: ``` class Base(DeclarativeBase): pass

class Foo(Base): name: Mapped[str]

x = Foo() ```

does not get caught as a type error statically, I'm assuming because all records are treated as mutable.

However, `x = Foo(name=2)` also doesn't get caught by pyright, which seems wrong. I could be misusing somehow though.

Totally agree that this is becoming the standard "reference architecture" for this kind of pipeline. The only thing that complicates this a lot today is complex inputs. For simple 1-2 page PDFs what you describes works quite well out of the box but for 100+ page doc it starts to fall over in ways I described in another comment.

We think about accuracy in 2 ways

Firstly as a function of the independent components in our pipeline. For example, we rely on commercial models for document layout and character recognition. We evaluate each of these and select the highest accuracy, then fine-tune where required.

Secondly we evaluate accuracy per customer. This is because however good the individual compenents are, if the model "misinterprets" a single column, every row of data will be wrong in some way. This is more difficult to put a top level number on and something we're still working on scaling on a per-customer basis, but much easier to do when the customer has historic extractions they have done by hand.

Cofounder here.

Great Q - there is definitely a lot of competition in dev tool offerings but less so in end to end experiences for non technical users.

Some of the things we offer above and beyond dev tools: 1. Schema building to define “what data to extract” 2. A hosted web app to review, audit and export extracted data 3. Integrations into downstream applications like spreadsheets

Outside of those user facing pieces, the biggest engineering effort for us has been in dealing with very complex inputs, like 100+ page PDFs. Just dumping into ChatGPT and asking nicely for the structured data falls over in both obvious (# input/output tokens exceeded) and subtle ways (e.g. missing a row in the middle of the extraction).

(author here) This really depends on what you're trying to functionally achieve, the organisation of your knowledge base and the fidelity you're looking for.

Let's take the example of "where should the assistant look for information on topic X", the absolute minimums would be to identify possible topics & the hierarchy of places you could look.

From the product engineering POV for the build your own path, for a well defined, limited search space this should be easily doable by a single engineer in a few days to a week. As this scales out to an entire company's knowledge base this quickly becomes a quarters long project for a small ML team to build the ongoing training jobs, data pipelines & monitoring tools required to make it robust.

From the POV of users, we designed our system to give our users the option to provide as much or as little feedback as they like. We can go quite far with upvotes/downvotes on whole answers, but we also accept per reference votes & full natural language feedback. We're still working on even deeper feedback mechanisms for power users & admins but we've typically seen the vast majority of users engaging in per answer voting & then exponentially smaller groups in the more detailed mechanisms.

The operator prompts becomes part of the input vector (it has a certain context depth it can accommodate), whereas the data it was trained on actually affects the models weights and biases. You can think of it like “evaluating this statement in light of the prior context against the training set”.

So the article is basically criticising databricks for only being worth 39bn? And then it’s titled “The End of Big Data”… what?

It is then safe to say that the only difference between programming paradigms is how long you keep stuff around and the space-time tradeoffs that these decisions entail.

That is absolutely not the only difference.

I agree with Martin Odersky that functional programming within an OO approach to code organisation is the most sensible trade off between maintainability and bug reduction.

I was an undergrad in biology and just finished my masters in comp sci last year. Now working at a FAANG as software engineer. It was 100% worth it for my long term career. Wouldn’t recommend for someone with CS undergrad already though if you’re only focused on career prospects.