bclavie

Hey! It’s more like comparing apples to apple pie.

BGE-M3 is a fine-tuned embedding models. This means that they’ve taken a base language model, which was trained for just language modeling, then applied further fine-tuning to make it useful for a given application, in this case, retrieval.

ModernBERT is one step back earlier in the pipeline: it’s the language model that application-specific models such as M3 build on.

They perform different roles, so they're not directly comparable.

Jina V3 is an embedding model, so it's a base model, further fine-tuned specifically for embedding-ish tasks (retrieval, similarity...). This is what we call "downstream" models/applications.

ModernBERT is a base model & architecture. It's not supposed to be out of the box, but fine-tuned for other use-cases, serving as their backbone. In theory (and, given early signal, most likely in practice too), it'll make for really good downstream embeddings once people build on top of it!

Sentence Transformers (https://sbert.net/), the most used library for embedding models (similarity, retrieval.)

We had a bit of a discussion around it, but I figured that 6 years warranted the prefix, and it's easier to remember in the sea of new acronyms popping up everyday.

Besides, PostModernBERT will be there for us for the next generational jump.

Thank you! We're fixing the link.

Hey, Ben here, one of the paper's core author authors. The responses you got were mostly spot on.

For (1), it's because BERT has both noticeably fewer parameters, and we're comparing at short context length (in the interest of providing a broader comparison), so local attention is a lot impactful than it is at the longer context lengths.

For (2), most LLMs are actually decoder-only, so there is no "encoder" here. But also, there's not a lot of LLMs in the ±100M parameter range in the first place!

Hey! Thanks for posting this. I'm the author of this post -- please feel free to shout if you've got any questions

Longer Background/Explanation:

I’ve been working on RAG problems for quite a while now, and it’s very apparent that solving real-life problems with it is very, very different from the basic tutorials around.

There are a million moving parts, but a huge one is obviously the model you use to retrieve the data. The most common approach rely on just using dense embeddings (like OpenAI’s embedding models), and getting the documents that have the embedding vectors closest to the query’s own embedding.

The problem is that in practice, it’s a bit of a Sisyphean task: you’re asking a model to compress a document into a tiny vector. And then, it must also be able to encode a very differently worded query into another tiny vector, that must look similar to the previous vector. And it must do so in a way that can represent any specific aspect of the document that could be requested.

The result is that dense embeddings require tons of data to be trained (billions+ pertaining examples), are relatively hard to fine-tune (must find a hard-to-strike balance), and have been shown many times in the Information Retrieval (IR) literature to generalise worse outside of known benchmarks. This doesn’t mean they’re not a very useful tool, but there might be more suitable tools for retrieving your data.

In the IR literature again, late-interaction models, or “sparse embedding” approaches like ColBERT or SparseEmbed are clear winners. They train quickly, need less data, fine-tune relatively easily, and generalise very-well (their zero-shot performance is never far behind fine-tuned performance!)

This is because these models don’t encode full documents: they create bags-of-embeddings! It’s a twist on the old-timey keyword-based retrieval, except instead of hardcoded keywords, we now use contextualised semantic keywords. The models capture the meaning of all the “small units of content” within their context.

From there, a document’s represented as the sum of its parts. At retrieval time, “all you need to” is to match your query’s “semantic keywords” to the ones in your documents. It’s much easier for the model to learn representation for these tiny units, and much easier to match them. So what’s the catch? Why is this not everywhere? Because IR is not quite NLP — it hasn’t gone fully mainstream, and a lot of the IR frameworks are, quite frankly, a bit of a pain to work with in-production. Some solid efforts to bridge the gap like Vespa [1] are gathering steam, but it’s not quite there.

[1] https://vespa.ai

Thanks! I agree -- I find it much easier to skim a few paragraphs than to skim through a video when trying to consume information quickly if I'm not sure I want to commit to a full, long vid. Hoping to make it useful enough that it ends up paying for its own server costs so I can keep it around!

Merci! It's early on but I'm quite happy with how the first prototype turned out.

> How do you break down the segments/sections? Is it just fixed time? What happens if there are more than one topic discussed in the segment?

Currently it's just a dumb fixed time rule, based on max video length (3 or 5mn segments). I played around a bit and it's the easiest way to implement things that works remarkably well. If there are multiple topics, there a few branching paths in the code, but a lot of it comes down to believing in the LLM's ability to make sense of it. I've got some ideas to improve, but would need a bunch of work to implement well.

> Are you using both chatgpt and mistral? Do you use them for different tasks?

There's a degree of A/B testing (well, "A/B testing", since we're not collecting feedback) where some of the summaries are GPT, some of them are mistral, mixed together for the same video. Mistral being superbly fast means it's also really useful to support the branching coding logic (e.g. something I'm working on right now is having an entirely different summarisation style if a video is about sports, and while a logistic regression would do that pretty well, it's not particularly robust, and won't tell me what sport it is if the transcript is full of typo) or to clean up the video transcripts.

Haha merci! Prends ton temps, pour le moment le tout tourne sur des crédits cloud gratuits alors la seule utilité du bouton premium c'est de faire de la lumière. Bonne chance pour ta recherche!

> Impressive, thanks. How could one run something like that on local videos ?

It depends how involved you'd want it to be really. You can get a very simple summary using something like Whisper to transcribe a video and having basic LLM calls. More involved summaries/segment breakdown/fine-tuned models would be a lot more work, but might not be needed for something quick with local vids?

> Btw I love the name.

Thank you! This is actually a project I had back in 2018ish, which fizzled out because I didn't have enough time to get good enough summaries going during the pre-LLM era. I let the domain name expire and a few weeks ago realised it was still free, so got building again and re-bought it!

Parsing pdfs (and powerpoints) and breaking them into "askable" chunks is definitely something we've been looking into and are keen to roll out. If you'd like to talk more about your use case definitely feel free to chuck us an email on the "reach out" email on the page!

I'm not too familiar with botco.ai, but from what I can see, we're approaching fairly different problems. DocAsker once deployed on an internal documentation (for example) would allow you to query it, for things like "What was agreed upon on the meeting about X?" or "What's the deployment procedure for the forecast tool?".

We haven't thought about marketing use-cases like botco seems to be focused on, and we're probably a bit too tight resource-wise to target this usage as of right now.

I've experimented with a few approaches and to be honest, kind of gone with what "felt best" as we're quite artisanal with our testing approach at the moment.

We try to always go for logical breakpoints (e.g. never in the middle of a sentence or explanation). Some docs are cut into smaller chunks because the way they're written works quite well for segmentation, and smaller chunks have the advantage of allowing more to be looked-up, so your semantic search is allowed to mess up as long as it finds 1-2 relevant context elements. For some, we felt like cutting into chunk was losing too much information, so we've added them as quite huge chunks. It feels suboptimal in some ways, especially in terms of performance and modularity, but we've also found that the model is very good at parsing a ±2k token length sample and getting the right info from it in most cases.

Ultimately there's no right answer and it's a case-by-case tradeoff.

It's kind of like that. You always have the option of fine-tuning, although that quickly gets pricey if you aren't self hosting (e.g. OpenAI bills an order of magnitude higher for serving fine-tuned models)

The constraints can be put in place through a bunch of different things. The prompt engineering is a big thing, instruction-tuned models can be pretty good at following very restrictive instructions. You do end up sacrificing some creativity in your answers by adding a lot of restrictions but it generally works quite well as a safeguard layer. A lot of the cool LLM applications are, first and foremost, proper prompting. Setting a low temperature is also key, as the higher likelihood suggestions _generally_ (but not always) are less made-up. ChatGPT makes this a bit harder as you have no control over the model parameters (temperature is OpenAI-set) and cannot control the original prompt, meaning you can't fully be in charge of the instructions it gets, so any mitigation to avoid hallucinations will have its limits.

After that yeah, the context documents you provide are pretty important in grounding it. It ties back in with the prompt, but you can more or less drill it into a low-temperature instruction-fine tuned model that if it can't find the answer within a set of documents you provide it, it should simply not answer. Again, you lose out in some contexts (it's a bad feeling on the user's end to not get an answer) but you also ensure that your model isn't live-freewheeling about a new framework called Reagular...

Sorry about that, I'll dig into the logs -- we had a lot more traffic than we expected overnight so it could be that the backend didn't scale quickly enough and ended up timing out some requests.

This is something I've thought about a lot, as I worked in legaltech for a few years. The main issue here however would be the (lack of) networking and breaking into the legal market, it takes a lot to get the ball rolling even if the tech is good, and more established actors are likely to do it first I feel.

We're working on a similar thing using the Notion API, so far synthetic tests are really encouraging, but we haven't quite tested it on a massive/sprawling corporate doc. Very excited about the prospect though!

Hi HN! I'm the other person working on this with Ankly.

This came up as a pet project as we were eager to put some LLM work into production. Currently piggy-backing off APIs, though the results with certain self-hosted models could be worse (but could be better), as he mentioned, we've ran some experiments with Flan-T5.

We have a bunch of current plans as to where to keep building on this, beyond improving the model/engine/prompting/etc... We're very keen to integrate more libs that we use (FastAPI and Pandas come to mind, in terms of sprawling doc), and adding a "Search through StackOverflow Answers" button, though testing how well our similarity look-up works on that front.

On the non-code/technical aspects, everything we've tried has been pretty encouraging, but has a bunch of different challenges. For documentation questions, we're trying to "ground" the model knowledge -- it probably knows a lot of react, but can't quite reference this exact bit of the documentation, or will use an outdated something, or this, or that... So we're trying to re-center and improve the knowledge of the original model and the way it serves it.

When we test the approach on in-house documentation (such as Notion), the problem is a bit different: in a lot of cases, _all_ the relevant information should be in the context, and we very much don't want the model to rely on whatever latent knowledge it has of "What was agreed with Joe about the framework swap?". We're not seeing much of it anymore, but even with synthetic data, we had some interesting situations where the relevant context wasn't found and some safeguards failed, so an entirely made-up Joe was purported as having approved to swap to Angular.

Happy to answer questions and discuss more about this -- LLM as the "logic" layer of document retrieval is definitely fascinating.