Datawizz

Model training 🤝 runtime

🚀 Datawizz now supports Tinker for LLM fine-tuning! Tinker is a training API from Thinking Machines that handles distributed GPU infrastructure at scale. We've integrated it into Datawizz to give you enterprise-grade training power without the usual complexity. What you get: ✅ Zero setup - No GPU configuration, no infrastructure headaches. Select Tinker, click train, done. ✅ Full control - Configure LoRA parameters, batch sizes, learning rates, warmup steps—everything you need for professional training. ✅ Real-time monitoring - Watch your loss curves and custom evaluation metrics update live in your dashboard. ✅ Custom evaluators - Add your own evaluation logic directly in the UI. It runs automatically during training so you can track what actually matters. ✅ Train to deploy - Once training completes, deploy your fine-tuned model to Datawizz Serverless with one click. No exporting, no uploading, no extra steps. Enterprise-grade training infrastructure, consumer-grade simplicity. 📖 Read the full guide: https://lnkd.in/gDZu6-W4 Ready to fine-tune? Try it today! 🎯 #AI #MachineLearning #LLM #FineTuning

Iddo Gino built and exited RapidAPI - a platform that served 10 million developers with at least one team at 75% of Fortune 500 companies using and paying for it. After the exit, he tried retiring. Got bored in weeks. Tried angel investing. Hated being the backseat-driver investor he'd always despised as a founder. But reviewing pitches revealed a pattern that pulled him back in: Nearly every AI agent company assumed models would simultaneously get 1-2 orders of magnitude better AND 1-2 orders of magnitude cheaper. "Wait, so everybody's basically banking for agents to work and for AI to work at scale on models getting significantly better and cheaper at the same time. And I just don't see there is any data to support that both of these can happen simultaneously." That was his "Big Short" moment. So he founded Datawizz to solve the unit economics problem through continuous reinforcement learning infrastructure. But building his second company revealed lessons that contradicted his first success: At RapidAPI, he had massive distribution - 10 million developers, 75% of Fortune 500. The synergy story was compelling: developers discover APIs on the marketplace, then their companies buy the enterprise product. The reality? "There were actually two very different businesses and the buying journey didn't actually go from one to the other." He could always find anecdotes of teams using RapidAPI before doing an enterprise POC. The data looked good. But the critical question he should have asked earlier: "Is self-service really the driver for why we're winning deals, or is it a nice-to-have contributor?" That narrative belief capped how big RapidAPI could scale. For Datawizz, he inverted the approach: → Spent months doing pure discovery, not sales disguised as research → Aimed for 29 of 30 minutes asking questions before explaining what they build → Qualified prospects by asking: "If we improved accuracy by 20%, how impactful is that?" → Disqualified companies who said "it's good enough" - even if they had budget → Focused on companies spending six figures monthly on LLM inference → Targeted the first $10M at believers in continuous learning, not skeptics The most valuable discovery calls weren't the ones that converted to POCs. They were conversations with people who thought about the problem completely differently. In hot markets with abundant budgets, it's dangerously easy to collect false positive feedback while building the wrong thing. His prediction: By 2030, 50-60% of AI tokens will flow through specialized, fine-tuned models instead of frontier models. Listen to the full episode of BUILDERS with Iddo Gino to learn how he's approaching category creation differently the second time: https://lnkd.in/ebA75-Gm

Use Datawizz to determine the GPT-5.1 reasoning effort level you should use!

Level up your prompting with Liquid Templates - now supported on Datawizz. Something interesting is happening at the prompt layer of LLM applications. What started as simple variable substitution has evolved into complex conditional flows, dynamic context management, and multi-stage reasoning—all happening in the prompt itself. We're essentially programming in natural language + template logic now. This makes sense when you think about it. Prompts are where your domain knowledge lives. They're where you encode business rules, handle edge cases, and manage context. As agents get more sophisticated, more logic naturally migrates to this layer. We just added Liquid template support to complement our Mustache templates at Datawizz, allowing for more intricate prompt and context engineering right inside Datawizz. Check it out here: https://lnkd.in/g4yCJB7E #LLMs #PromptEngineering #AI #TechnicalArchitecture

The death of RAG? Do we still need RAG with larger contexts? Short answer - yes, but a lot less than we used to. - RAG was broadly necessary when model contexts were very limited - so you had to send only the most relevant info - New models have much larger context windows AND are much better with larger contexts. Farther, with prompt caching and other methods -- lager contexts are more economically feasible now - This means that for more static content - you can pass it all in the context window -- even if there's a lot (100k+ tokens). - So for instance, if you are building an agent and want to give it access to platform docs, you can just put everything in the context (rather than use RAG to retrieve specific information). - For bots that handle user specific data, we still technically need "RAG" - we need to retrieve all the user specific information. But we may not need full-blown RAG with similarity search and vectorized content - just static retrieval. You can just "dump" all the user data into the prompt. RAG might not be “dead” yet, but its default‑status is. In 2025, start with the simplest viable architecture: if your knowledge base fits comfortably in 200k–1M tokens, skip the retrieval stack and lean on prompt caching. Add retrieval only when scale, freshness, latency or privacy truly require it. The result is less infrastructure, fewer failure modes, and often better answers. Read our full post:

Are newer AI models hallucinating MORE? Hallucinations have plagued early AI models since the first research LLMs were introduced - but many assumed that this is a technical bug that will get solved with newer version. New reporting from OpenAI suggest that newer models - especially reasoning models - actually hallucinate more, not less. It is apparent that hallucinations are not a "bug" per-se, but a byproduct of the way LLMs are built and trained. It's unclear that the bigger and better approach for model scaling will have any positive impact on hallucinations in the near future. Turns out hallucination reduction is where Specialized Language Models shine. By fine tuning SLMs with custom, human labeled & verified data (RLHF), our customers have been able to meaningfully reduce hallucinations in their AI applications. Platforms like Datawizz help companies build up datasets of past LLM interactions. With human labeling, we can identify hallucinations and tune better specialized models to avoid these hallucinations. If you are dealing with hallucinations, check out other blog post on using RLHF - alongside 5 other methods - to reduce LLM hallucinations. Link in the first comment.