Lokalen Klassifikator nach Jev-Vorbild mit Claude Opus 5.5 erstellen

VideoCURTAnleitung

CURT zeigt, wie sich mithilfe von Claude Opus 5.5 ein lokales, auf Reiseangebote spezialisiertes Klassifikationsmodell trainieren lässt. Inspiriert von Jev ordnet das System Eigenschaften wie Stornierungsbedingungen oder Poolzugang ein und kombiniert Textklassifikation mit Bilderkennung.
Beim Abspielen wird YouTube (youtube-nocookie.com) geladen.

Das Wichtigste

  1. Vierstufiger Prozess: Passendes Open-Source-Modell für lokale Hardware finden, Ziel und Label definieren, Benchmarks aufstellen und multimodale Bildprüfung ergänzen.
  2. Claude Opus 5.5 schlug für die lokale Textklassifikation ModernBERT vor; als multimodale Ergänzung zur Bildprüfung dient Diffusion Gemma.
  3. Klassifikationslabel umfassen Kategorien wie 'meets', 'violates' und 'can't tell' (mit Begründung wie unzureichende Belege), ergänzt durch Konfidenzwerte.
  4. Vermeidung von Overfitting durch getrennte Test- und Validierungsdatensätze sowie den Einsatz von Kontrollgruppen und Versionsmanagement.
  5. Im gezeigten Test stieg die Genauigkeit des lokalen Modells durch iteratives Feedback und Nachtraining von rund 60 % auf 95 % (im Vergleich zu etwa 98 % bei Jev).

Warum das relevant ist

Encoder-basierte Klassifikatoren ermöglichen spezialisierte Aufgaben wie Dokumentenprüfung oder Angebotsabgleich lokal und ohne laufende Tokenkosten großer LLMs auszuführen. Claude Opus 5.5 kann dabei als Entwicklungs- und Feinabstimmungs-Assistent dienen.

Einordnung

Das Tutorial verdeutlicht den Unterschied zwischen generativen Modellen und reinen Encoder-Klassifikatoren. Statt aufwendiger Prompt-Ketten auf großen Sprachmodellen wird ein leichtgewichtiges Modell für einen spezifischen Datensatz trainiert. Die zusätzliche Bildprüfung verhindert Text-Fehlklassifikationen (etwa die Verwechslung eines Teichs mit einem Pool), während Claude Opus 5.5 die Orchestrierung, Evaluierung und Code-Erstellung übernimmt.

Transkript

Vollständiges Transkript anzeigen (3.272 Wörter)
So I took the idea behind Jev and made a version that runs entirely on my computer, completely for free. It even understands images, which is something that the current version of Jev doesn't support. And this isn't sped up, this is the actual speed and Cloud 5.5 Opus helped me build it. Now, imagine you run a travel agency. You've got 12 customers, each with their own wish list and budget. One might need a pool and another one might need accommodations for a late flight. One's budget-conscious, and another wants every single box ticked. Your job would be to match all of these travelers with a holiday that fits. And instead of spending tons of tokens on tens, if not hundreds of examples, you can run this for a fraction of that cost. So instead of showing you how to build a video game or a $10,000 website with this brand-new Opus model, I'm going to show you how you can push it and drive it to do something actually impactful. By the end of this video, even if you're non-technical, even if you have no idea what machine learning is, and the concept of Jev is still fresh in your mind, I'm going to show you how you can get something like Opus to build an entire framework for you, and I'll give you a series of cheat codes along the way. Let's dive in. Now the big picture with our experiment is that our Jev clone isn't assessing individual travelers. It only reads information about the holiday and the hotel and answers a series of questions about it. Questions like, is there free cancellation? Can people use the pool for free? Is a guided hike included? Are there stairs at the entrance? Is it accessible to someone in a wheelchair? Then all that happens is as soon as we classify yes or no for each one of these questions, we just go down all of the wish list from that traveler, and we can very quickly assess whether or not we have a match. Now, building something like this yourself might feel daunting, especially if you're non-technical. But it's actually composed of four core steps. Now, step one is finding a model. And this is an open-source model that you can give to your Cloud Opus, so it can look at it, look through all the code, and see where it can specialize that specific model on whatever you're trying to classify. If you don't know what to look for, I'll show you how we can do this really quickly. Step two is you explain to Cloud exactly what you're trying to specialize in, what you're trying to classify, and what is the overall goal. The more clear and cohesive and explicit that goal, the more likely it will be able to fine-tune this open-source model and get it as close to Jev as possible in terms of performance. Step three is probably the most important, where you have Cloud not only run experiments on the model that it fine-tuned, but you basically give it a rubric, a benchmark. Out of 10 people, or out of our 12 travelers, how often are we tolerant of mistakes? What kind of accuracy are we going for? What does accuracy mean? Once you give it all of that description, it can have a rubric and continually keep going, especially if you use something like a slash goal with Opus. And last but not least, I am not a prodigal genius in terms of being able to add multimodality to something that Jev hasn't even figured out yet. But what has happened is that there are a series of open-source alternatives, and all you have to do is point Cloud to those repos or those models. It can learn from that architecture and just apply it to your specific use case. Now before we keep going, I'm going to explain some key terms very quickly, so I don't lose you along the way. So big picture is Jev is what's called pretty much a classifier model. Specifically, it's called an encoder-only model. What does this mean? This just means that it's meant to understand things and bucket them. If it was a decoder-only model, then the model would only be able to generate things. If you had an encoder-decoder model, then it's a model that can both understand and generate things, which is your average LLM. So to help Cloud know exactly what we're trying to achieve, we're going to do some context priming, which means we're just going to explain exactly what we're going for. So we can feed it Jev's documentation, which is open. We can also feed it examples of repos or repositories of existing open-source alternatives. So in this case, I'm just going to say open-source Githubs. And then on top of that, we can tell it exactly what we're trying to classify, classification buckets. And then once you give it all this information, we can tell it, go find me a model that can run on my specs of my computer if you want to run this locally. If you want to host it, then you absolutely can just tell it that. But as soon as you want to run it on your computer, it'll find a model on Hugging Face that could be small enough for you to fine-tune. And even if you're not matching the quality of Jev, it could still do a decent enough job that it's more than proficient at your specific task. So in terms of repos, you can feed it something like Open-Jev and newly, there's something called Diffusion Gemma, which gives it that multimodal ability to analyze images in tandem. In my case, Cloud recommended this model that's called ModernBERT. If you've never heard the name BERT, it's basically OG, an OG to Jev that existed long before that wasn't as generic in terms of being able to apply to all kinds of circumstances, topics, and objects. But because this is open source, and you can just download it on your computer, not only do you have access to the weights, the entire infrastructure, but it's something that Opus can take and run with. Now in our case, we want to take this vanilla model and make it a specialist at the travel domain. But for you, you might want to make it a specialist at tagging insurance documents, going through legal cases, whatever it may be. Looking at studies at scale, but what you want to do first, just to make sure that your fine-tuning works, is you want to choose what you want to classify or tag first. And again, similar to the Jev model, you can make it binary, yes, no, or multiple choice tagging, or a third one that's rubric-based where zero stands for X, one stands for Y, and you have that model automatically classify based on that criteria. Once you measure the before, then after fine-tuning it on your specific use case, and again, I'll give you the prompts to get there, then you'll see how quick and how close you can get to something like Jev. To get this process rolling, you might want to send a prompt like this, where you say, "Set up this repo on my computer and launch the travel demo with the supplied model. Check my machine, download the required files, and add image understanding if supported. And you can do this, once again, by hooking up to a GitHub repo that is open like Diffusion Gemma, like I showed you. You would feed that in, it would go and analyze that, maybe ask it to spin up some sub-agents to each take a peek at different parts of the architecture and come back with the full plan. And next, we need to define the goal, and we want to make this as clear and coherent as possible. As long as you can explain this in plain English, or whatever your language of choice is, then it will be able to optimize for it. So in our case, we're saying, "Build a travel specialist that checks four things: whether a property has a full cash refund, arrival after midnight, included pool access, or an included guide hike." And this is probably the most important thing where you tell exactly what the options are. Answer meets, violates, or can't tell, basically, I don't know for each. And again, the beauty of these Jev-like models is it spits out a confidence score. So unlike a normal language model where it just gives you an answer, and you have to ask it, "Are you sure?" and it may or may not confirm it, you will get a probabilistic probability score out of each answer. To complement the text classification, we could tell it to keep photo evidence separate. So make the classification first, and then to support your confidence, go and take a look at the image to see. If you see an image of a pool, and it classified it as not having a pool, then this gives you a second way to correct that misclassification. Now, I'm going to give you the full prompt and a guide so you can do this for yourself. But I wanted to break it apart into small layers, so you can see how each one adds to the next. The first part is the job, and this is where you outline what your inputs are and exactly what the different options for tagging them should be. Number two is if you haven't chosen a model yourself, and you want to run this locally, you would ask something like Opus to go through your entire specs of your operating system, go on Hugging Face or similar, and find the perfect model that could be fine-tuned in a reasonable amount of time. One thing to know is that this process can take hours, especially if you don't have a GPU in your computer. This could take anywhere between three to six hours every single time you retrain. So the better you plan, the better the likelihood that you can go to bed, wake up, and have a tested model that is not Jev level, but it is close enough where it's useful. Now part three and part four are related, where in part three, you're specifying where you're going to store each version of the model. Just in case you want to go from V1 to V2, and you want to make sure that you're one improving, and if you don't improve, and you're actually go down in performance, you can always go back. And similar how you would run a clinical trial, ideally, you have your vanilla model, and then you have your trained model, and then you have a control group, which could be a frozen version of V1 or V2. So you can always make sure that you're constantly improving, and you have different reference points for future versions. If you want to tinker before you run a test for hours, you could take a very small portion of a dataset, have a very small test size, and then run that and see, is there any form of potential here for your specific use case? If it's something where it naturally involves tagging, classifying, then most likely the answer is yes, especially if you have Opus orchestrating, taking a look at the infrastructure and figuring out how you can get closer to your final result. Now if you don't know how to properly benchmark a trained model, luckily, things like Opus will know. So it will decide on these different factors like accuracy, macro F1, if those words are complete gibberish to you, don't worry about it. You can look into what they mean, but overall, accuracy means something slightly different when it comes to classification. And one thing you really want to pay attention to is that your model doesn't memorize answers, it actually has some form of understanding. If you don't know what I mean, just give me two seconds and I'll break it down on an Excalidraw. But the last two things is addressing how you're going to weave in images into the classification and delivery in terms of what is the final product, which in your case will be a model, ideally, some testing. You can ask it to use an image generator like Gemini or GPT-2.5 Image to create a series of infographic benchmarks showing what is before, what is after, what is the scale against Jev. And if you give it a Jev API token, you can have it run the exact same experiment across different versions of the same fine-tuned model and Jev, so you have a full understanding. Is it good enough to replace it, or can you maybe just use Jev for your specific use case instead? Now, going back to testing, like I said, there's a hidden trap that might catch you if you don't know what to look for. And this trap is called overfitting. And what this means is, you have this algorithm, this model, become tuned and starts to memorize the shape and the examples of your data, so when you classify it on that data, it does a great job, maybe it's 95% accurate. But in reality, if you fed it to unseen data, data that it has not seen or classified before, it completely plummets. And this relates to a little saying we have in my mother tongue, which translates to roughly, "He has memorized, he has not understood." So the classifier doesn't actually understand the data. It doesn't understand how to tag the different cases. It's just basically used to all of its training. And the way you get around this is you make sure you keep a portion of your data, we call this the test or the validation set, where it is unseen data that the classifier has never seen before, and you run a test to see how well is it able to tag it, and you can use something like Jev as your control group to see how well does Jev do on this unseen data, compared with our fine-tuned model. And the last categories that you have to tag, the more it's likely to generalize more quickly. So in our case, we could just give it three choices if you wanted to, which is cashback, hotel credit, or I can't tell. The training process itself could look like this where you feed this sentence that says, "Contact the booking office to learn which cancellation rules apply." And then you ask the question to the model, "Can I get a full cash refund?" And if it's well-trained, it should be able to tag it as can't tell, and then it has a sub-tag that says insufficient evidence. And behind the scenes, you won't have to deal with this, but this object that you're trying to classify will look like this where you have the question posed in a very similar way that you would present it to something like the Jev API. These are the options that it can pick, and then over time, you reward or you punish it for the right or wrong answer. And to make sure that Opus doesn't overfit the model, one, you could tell it to make sure it doesn't overfit, it will know without you having to fully understand what it needs to look for. And number two, it will set aside a portion of your test data, a portion of your real-world cases to see, is it performant on those unseen cases as well? To give you a preview of the process, the first version of our model was only 60% accurate, whereas Jev's was 98% accurate at tagging the right cases for the right travelers. One thing that's helpful is to go through the answers that it got wrong yourself, then give feedback to Opus and tell it why it's wrong, to give it additional context for it to retrain the model. And once you do that, in our case, we went from 60% accuracy to 95% accuracy. So I wasn't able to quite beat Jev, but I got close enough on a local model running on this computer that runs at the same time as multiple other processes, that was definitely worth the squeeze. And just in case it's not clear how this whole image recognition part would work, you would have an image of the hotel, and then it would specify a portion of it, and it breaks it down into individual pixels. Those pixels would be understood then combined with the classification of the pure text of the offer from that holiday or that hotel. So in case the text-based model tagged the holiday as having a pool that guests could use, you could have an image like this where very clearly this is not a pool, it is a pond. And through the image recognition, it would tell you, "This is a pond," so it'd be able to negate the wrong classification from the text model. So the result is that you have a model that can programmatically and very swiftly go through all these properties and tag it whether or not it passes or fails each condition. And in case you wanted a quick and dirty way that you could tinker and build a version like this yourself, you could go to something like Grok or SuperGrok and say, "Find every open source derivative of Jev that has a decent number of stars for me to inspect that's come out in the past week and has an MIT license." Then once it goes through and finds everything like Jev-like, Open-Jev, which is something that I used, and it goes down, then you can send a prompt like this where you say, "Create a prompt for Claude 5.5 Opus based on their guidance on how to use the model to fine-tune it for my travel data where you can tell it exactly what you're optimizing for, and find me a Hugging Face model that it can fine-tune." Then it will go, research, like you can see here, the public docs and Opus prompting guide. Then we get a system prompt like this, which will save you tons of time, and especially if you're not technical, it will take care of specifying all these little micro details to help it shape the experiment that much more easily. And that's pretty much it. So with models like Opus 5.5 and beyond, we now have the ability to take and create our own models just like Jev that we can specialize on our specific use cases or domains. And like I mentioned, I'll make the full prompt and a guide that you can feed to your AI of choice available to you for free, down in the second link in the description below. And as always, if you want to stay 10 steps ahead in the bleeding edge of AI, want access to my exclusive training, resources, GitHub repos that you can use to supercharge your AI learning journey, then check out the first link down below, and maybe I'll see you in my Early AI-dopters community. And for the rest of you, if you found this video helpful, I'd super appreciate a like and a comment, it really helps with the reach, and I'll see you all in the next one.

Links und Tools aus diesem Beitrag

Zusammenfassung von KI erstellt (Gemini 3.8 Flash, 27. September 2026). Sie kann Fehler enthalten – maßgeblich ist die Originalquelle.

Inhaltlich ähnlich, ermittelt über die KI-Suche.

  • X-Post:Ruben Hassid

    Jev von TypeSafe: Schnelle KI-Klassifizierung statt geschwätziger LLMs

    Ruben Hassid beschreibt das Tool Jev des Anbieters TypeSafe als extrem schnelles, kostengünstiges Entscheidungsmodell. Statt wie herkömmliche LLMs lange Textantworten Wort für Wort zu generieren, liefert Jev direkte Auswahlen aus vorgegebenen Optionen inklusive Konfidenzwert. Hassid zeigt Setups in Claude Code sowie Codex und demonstriert Anwendungsfälle zur Filterung von Kontakten aus LinkedIn und Gmail.

    1632Lesezeichen112.511Aufrufe

    KI & AI· Tool

  • Video

    Video:CURT

    Entwurfsmuster für Jev: Wie Entscheidungsmodelle Workflows steuern

    Das Video stellt das Entscheidungsmodell Jev von TypeSafe vor, das für schnelle, kostengünstige Mikro-Entscheidungen statt für Freitext-Antworten konzipiert ist. Anhand von konkreten Beispielen werden drei Antworttypen, zehn funktionale Formen und vier Architekturmuster erläutert.

    KI & AI· Anleitung

  • Link:oumi.ai

    Oumi: Plattform zur Entwicklung und zum Betrieb spezialisierter KI-Modelle

    Oumi positioniert sich als AI Factory zur Erstellung, Bereitstellung und kontinuierlichen Optimierung eigener KI-Modelle. Anstatt ausschließlich auf generische Frontier-Modelle via API zu setzen, ermöglicht die Plattform das automatisierte Training und Feintuning spezialisierter Modelle auf Basis eigener Unternehmensdaten.

    KI & AI· Tool

Lassen Sie uns über Ihr Projekt sprechen

Standorte

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Wien
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Dieser Inhalt wurde teilweise mithilfe von KI erstellt.