Thread

Beating GPT-5.6 Sol on retrieval with 100x cheaper open models

409 points · 114 comments · moonikakiss

mrinterweb · 1785956587 · focus · HN ↗
There is so much opportunity for purpose built models like this. Ideally a harness should spin up a subagent to offload to targeted models for specific tasks like this. I know this is not a novel idea. Claude code does some of this by handing off the "explore" agent work to haiku. I just love seeing that specialized LLMs are being developed.
1. foota · 1785956634 · focus · HN ↗
  I feel like the future is people building applications with tightly integrated LLMs that work hand in hand with the application's own lifecycle and code.
  I also didn't realize that people were using agentic harnesses for search, it's an interesting idea. If the context length is short enough it should be fairly cheap compared to running "normal" agentic coding workloads where you have O(100k) context length for doing almost anything.
  1. kumama · 1785980427 · focus · HN ↗
    castform founder here. that's a future we are really excited about too :) ideally, you can post-train the llm within the application itself, as it's being used. both interesting infrastructure & algorithmic challenges here
2. Malp · 1785957063 · focus · HN ↗
  There are! Chroma has Context1, SID has SID-1, and you'd actually be surprised at how easy it is to post-train your own with pretty good pass@ recall@ ndcg@ etc.
  There's also Hornet who have shared some interesting talks & blogs lately. I don't know that I'd exclusively use agents for retrieval the way Neon outlines here as well. I think distillation similar to what ZeroEntropy has done for bespoke retrieval & reranking with _some_ agent manipulation on top-k results works better (IME).
3. devolving-dev · 1785957660 · focus · HN ↗
  Models keep on improving though, so doesn't fine tuning become an ongoing task with ongoing maintenance burden?
  1. kumama · 1785958456 · focus · HN ↗
    (one of the blog post authors here) -> once you set up a finetuning pipeline, it's often trivial to rerun it on top of a new open weights model. so, it's orthogonal to base model improvements
4. Razengan · 1785960393 · focus · HN ↗
  > There is so much opportunity for purpose built models like this.
  OpenAI etc could themselves do this, and maybe they already do? Where the public-facing interface delegates to multiple little goblins behinds the scenes
  1. mrinterweb · 1785960780 · focus · HN ↗
    Exactly. There could be a lot of value for inference companies to do this. Could save a lot of money being able to hand off highly repetitive known tasks to far smaller specialized models.
  2. kumama · 1785981027 · focus · HN ↗
    castform founder here. openai actually deprecated their finetuning apis a few months back weirdly.
5. phainopepla2 · 1785961111 · focus · HN ↗
  > Claude code does some of this by handing off the "explore" agent work to haiku
  This is no longer necessarily true. As of 2.1.198 [0] (released July 1st): "The built-in Explore agent now inherits the main session’s model (capped at opus) instead of running on haiku"
  [0] <a href="https://code.claude.com/docs/en/changelog#2-1-198" rel="nofollow">https://code.claude.com/docs/en/changelog#2-1-198
6. benjiro29 · 1785962627 · focus · HN ↗
  > Claude code does some of this by handing off the "explore" agent work to haiku.
  That is not handing off to a specialized model, its just handing off to a lighter and interior model (compared to the parent model). That by itself can create issues like the lighter model not capturing all the data that the parent needs.
  The idea is that we get specialized models that are better then general purpose models. But its rare for a specialized model to beat a strong general model.
  There is a reason why we hear less about this idea of smaller expert models, because large strong models to the tasks just as good.
  And if the tasks is repetitive to the point that specialization is useful, you can get into a situation that your better off having a program written for that reputative nature, then delegating to other models. And then have the main strong model, deal with the (semi)cleaned up data.
  1. BikiniPrince · 1785963940 · focus · HN ↗
    You can register models with mcp. I think it’s an expensive solution, but it is available in the framework. I use a light weight bus protocol that lets agents interact and pass short messages with pointers. It’s very efficient.
  2. tyre · 1785970155 · focus · HN ↗
    > There is a reason why we hear less about this idea of smaller expert models, because large strong models to the tasks just as good.
    Smaller models are cheaper, sometimes faster. I agree that the “we’re an LLM fine-tuned for X” hasn’t worked out because you can just train Claude to do X (and Anthropic will), but not burning Opus/Fable tokens on dumb-but-token-heavy tasks is good sense.
    As we move from “integrate AI into Y” to “optimize the ROI on Y”, we’ll see more of this.
    kumama · 1785982579 · focus · HN ↗
    castform founder here. the roi optimization makes sense. i think there are lots of usecases for which even a 2% gain in accuracy can be quite useful. off the top of my head
    - high volume customer support. higher accuracy means fewer escalation, reducing labor costs - fraud detection. catching even one extra fraud attempt could mean a lot in savings - and ofc the classic ads use-case where at scale bps in improvement could mean millions in revenue :)
    simianwords · 1786001448 · focus · HN ↗
    Would a bigger model be able to beat yours if some effort were put into prompt?
    dkersten · 1786010596 · focus · HN ↗
    At what cost though? “Beating” isn’t enough if it costs 100x or even 10x the amount.
    kumama · 1786025579 · focus · HN ↗
    the bigger model would still cost more :) at the same time, i see prompting as being orthogonal to post-training. i'd imagine post-training a smaller model with a better prompt would make it perform even better
    simianwords · 1786040990 · focus · HN ↗
    yes, can you show me tasks where this is true?
  3. kumama · 1785980993 · focus · HN ↗
    castform founder here. while it's "rare for a specialized model to beat a strong general model" today, i think the tech/knowhow on how to do so is getting there. we see some early signs of this in industry e.g.
    <a href="https://shopify.engineering/sidekicks-continual-learning-loop" rel="nofollow">https://shopify.engineering/sidekicks-continual-learning-loo... <a href="https://thinkingmachines.ai/news/learning-to-replicate-expert-judgment-in-financial-tasks/" rel="nofollow">https://thinkingmachines.ai/news/learning-to-replicate-exper... <a href="https://castform.com/blog/elsa/" rel="nofollow">https://castform.com/blog/elsa/
    at the end of the day, models are only as good as the data they're trained on. and if one has access to proprietary data, it should yield specialized models that do better than larger general models
  4. nullbio · 1785997626 · focus · HN ↗
    > The idea is that we get specialized models that are better then general purpose models. But its rare for a specialized model to beat a strong general model.
    Are you sure about that? I mean, MoE is basically an array of specialized models. This beats single-model general purpose performance.
    Clever routing systems also seem to indicate frontier or frontier-beating capabilities at reduced cost, such as Fugu.
    Further to this though, I think it hasn't been pushed hard enough. We're not going down far enough in the abstraction chain. Most peoples idea of 'specialized models' is an LLM trained on a particular domain (like math vs coding vs creative writing), where-as it should be going lower-level than that and incorporating not only more abstract and smaller specializations of LLMs, but entirely different types of AI models, classifiers, etc.
    I also think the reason we don't really hear much about this (yet) is because there's no incentive for the best AI researchers/labs to go down this direction because it's better suited for local-processing over your entire codebase, but the labs all want you to perform inference on their servers and spend your money there, rather than spend your own compute to increase intelligence. They have a larger incentive to try and scale in different ways. We'll have to rely on open-source for this one.
7. oliver236 · 1785965438 · focus · HN ↗
  this is exactly what leopold talks about in situational awareness
8. try-working · 1785966371 · focus · HN ↗
  yes, and this is why we need model routing
  1. kumama · 1785977011 · focus · HN ↗
    castform founder here: totally! we also think model routing is also a post-training problem i.e. getting a model to predict the difficulty of a task and match it to the right model -> we're gonna be sharing more on that soon :)
    dd8601fn · 1786026883 · focus · HN ↗
    I’ve been trying to do this with a pet project and admit that I’m getting terrible results. My small llm as a classifier/router stage just isn’t getting the job done.
9. nikcub · 1785966581 · focus · HN ↗
  There has been an over-obsession with frontier models and benchmarks. Most of the work will be done by task specific models. You don't put Phds on the factory floor.
  1. bizzletk · 1786014500 · focus · HN ↗
    If the PhDs don't cost very much more than your equivalent of factory-technicians but still get the job done, why wouldn't you do that, at least in the blunt case before cost control rears up?
    polotics · 1786041459 · focus · HN ↗
    because they will take initiatives for localized improvements you don't want them to take
  2. dwaltrip · 1786037165 · focus · HN ↗
    This only works if the tasks are actually specific and don’t benefit from broad competency.
    IMO, this doesn’t match most things that people use LLMs for.
10. nullbio · 1785997176 · focus · HN ↗
  Yep. It's a real shame that the labs are incentivized not to go in this direction. They all want to try and suck us into the cloud and take away full control and local processing, but there's far more opportunity by building small AI systems and tools into the harness itself to make the models more intelligent.
  They naturally don't like this direction, because it draws the intelligence away from their systems, and onto the local machine, where idea moats cannot be protected and hidden, and costs can be dramatically cut. Imagine though, how powerful our harnesses could be if the best researchers were thinking about how to utilize the power of the gaming GPUs that most PC users have (or can get), to supplement the frontier model processing. Instead of trying to have the frontier model do everything, the frontier model can serve as the orchestrator over all of the smaller dedicated harness models. Right now my rtx4090 sits there unused for most of the day while I'm paying for inference in the cloud... It's such a waste of parallel intelligence bandwidth.
  I'm not just talking about LLMs either, most people seem unaware that there are a plethora of dedicated AI models for all sorts of conceivable pipeline usecases, from all sorts of classification tasks all the way down to things like code duplication detection. Right now the LLMs completely suck at cleaning up code and architecture, and a big part of that is because the frontier LLM cannot fit your entire codebase + all of its long-chain reasoning into the context window. But using small local models and tools bypasses this problem because small fast models can iterate over an entire codebase quickly. A harness that creates a big model bundle + routing system + DAG-based memory/execution management over all of these has the potential to be incredibly powerful.
  Even better, building a framework around this concept and having the frontier model dynamically and adaptively generate the ideal execution system for any given task/domain. We're working on coding today? Okay, here's a recipe we can use: ..., and it generates a local model pipeline execution system that it feeds all of your prompts through in real time by using pre-defined or shared recipe building blocks, etc... Lots of interesting possibilities.
11. kinnth · 1786002877 · focus · HN ↗
  isn't this also the threat to frontier AI houses? As in they want you to expend tokens in their ecosystem, but the optimization at 100x is their profit?
  1. kumama · 1786026216 · focus · HN ↗
    castform founder here. i'd say it's a threat but the frontier ai labs' argument would basically be that the market opportunity for intelligence is infinite so it doesn't matter. at the same time, i do believe there will continue to be a massive, growing market for big labs, esp for super-frontier use-cases. today that's longer-horizon coding tasks but in the future it can be things like scientific discovery, etc.
12. boonzeet · 1786019410 · focus · HN ↗
  This is how Sakana's Fugu model works, achieving similar performance to Opus/Fable with a mix of open source & mainstream LLMs.
13. drob518 · 1786026886 · focus · HN ↗
  IMO, purpose built or “adapted” models are The Next Big Thing. If I’m using a model to write Python code, for instance, I really want the 8B or 27B expert model for exactly that, which would also be runnable locally. I don’t care about the 1.8T model that can answer every query under the sun and that only runs in a remote data center.
[deleted] · 1785956805 · focus · HN ↗
[deleted]
ramon156 · 1785957053 · focus · HN ↗
Bit unrelated, I realized that z.ai gives you access to deepseek 4 flash. It's incredible how well it performs when given a detailed spec. I'm not sure I've seen a model one-shot like that, and I was already impressed by gemma 4's speed and efficiency.
1. swiftcoder · 1785958070 · focus · HN ↗
  Deepseek flash (especially after the recent update) has to be one of the most slept-on models. Price-performance is ridiculous, and its available on a number of cheap coding subscriptions
  1. try-working · 1785966476 · focus · HN ↗
    Flash is the most used model in the world since last week
2. esafak · 1785983743 · focus · HN ↗
  > I realized that z.ai gives you access to deepseek 4 flash.
  How? Can you give details?
aliljet · 1785957209 · focus · HN ↗
There is a more serious question in here that's not being answered. How effective is the retrieval in finding buried needles in larger and larger haystacks. And there's a correlary question, how effective could you be in finding paired needles in that haystack where you need to hold a needle to unlock finding another needle.
1. Foobar8568 · 1785961985 · focus · HN ↗
  Considering the state of the field ( RAG/retrieval/evaluation) I have 0 trust in it, even more if it's closed source with bullshit claim like that.
  Everything is vibe sloped to death, and dead after a few months to a couple of years (and not hard to be 100 cheaper than GPT-5.6 sol ... DS is basically free and I guess already 100 times cheaper or more, and here another slope ).
  1. kumama · 1785981382 · focus · HN ↗
    castform founder here. we should have made it more prominent on the blog but here's the full code example: <a href="https://github.com/castform-ai/benchmax/tree/main/examples/neon_rag" rel="nofollow">https://github.com/castform-ai/benchmax/tree/main/examples/n...
    sreekanth850 · 1785988378 · focus · HN ↗
    Are you using blind chunking or section aware chunking?
    kumama · 1785989407 · focus · HN ↗
    for the example here the chunking is section aware -> but the general training data synthesis pipeline is agnostic to type of chunking
    sreekanth850 · 1785989924 · focus · HN ↗
    if chunking is section aware, how do you manage large section embeddings?
    Foobar8568 · 1785990265 · focus · HN ↗
    Thank you for the github link, what is the license? I went briefly over several repo, unless I missed it somewhere the license was often missing.
    kumama · 1785990752 · focus · HN ↗
    it's apache 2.0: <a href="https://github.com/castform-ai/benchmax/tree/main?tab=Apache-2.0-1-ov-file" rel="nofollow">https://github.com/castform-ai/benchmax/tree/main?tab=Apache...
2. BikiniPrince · 1785964159 · focus · HN ↗
  I use detailed project files. It has data regarding the project and subtasks as well as task status. It doesn’t depend on agent context and it’s managed to keep the agent on track. Feature creep with the new models is a very real issue. Capturing principles and how to reconcile tasks helps too. Even today it brought up a source of truth issue it had detected. There were multiple authorities born out of a patch and it used that principle to highlight and resolve the problem.
3. seahyinghang8 · 1785982743 · focus · HN ↗
  <founder of castform here> tldr: we generated synthetic training questions from the gitlab product handbook.
  totally agree that this larger corpus with harder to search information would be a good way to stress test - i'm sure we will encounter more interesting problems to solve. love to hear any suggestions of corpus to search against that is not just the public internet
  the training run link is also a little buried but here, you can see the comparison against the various models and their exact traces: <a href="https://app.castform.com/train/a7a898f6-d802-4908-b044-acb812f14a48?tab=comp" rel="nofollow">https://app.castform.com/train/a7a898f6-d802-4908-b044-acb81...
richwater · 1785957598 · focus · HN ↗
One thing that plagues [insert current FAANG] is the large amount of corpus knowledge that is outdated/misleading or just plain wrong. I'm curious how this addresses that if it's deriving the reward function from the corpus itself.
1. seahyinghang8 · 1785980875 · focus · HN ↗
  (founder of castform here!) - having worked at FAANG / big tech, i totally get this. our example was on gitlab's open source company handbook but i think a real company's corpus is way more messy and has many sources of truth.
  a few ideas i have yet to validate are: - prioritize recently updated docs when generating the training questions (assumption those docs are more correct than others) - actually including contradicting documents that talks about the exact same topic might be a good training example - ideally the model should surface all the relevant info it can find, and explain what it has found. (usually contradiction comes from the fact that the later document is the updated stance) - you could also mine high quality Q&A from public slack / communication channels where questions were asked and someone else in the team linked some docs / answer. those are strongly validated "ground truth" answers
  1. richwater · 1786026566 · focus · HN ↗
    Thanks! I think those could all be good heuristics.
JCharante · 1785957691 · focus · HN ↗
I have done my own testing and found that smaller models can beat their larger siblings on fact retrieval from documents. I haven’t investigated it in depth with a large enough dataset but my guess is that larger models overthink it while smaller ones just do it. I would like if they compared this with 5.6 Luna instead.
1. andrenotgiant · 1785958098 · focus · HN ↗
  Any data or public links you can share? That surprises me
2. barake · 1785958146 · focus · HN ↗
  Anecdotally, it feels like Opus, Fable, and Sol "get distracted" when you use them for writing code. Great at reasoning and coordination but they will go off on a tangent and refactor half the code base. I only use them for reasoning (of course) and coordinating subagents.
  1. CoolCold · 1785997669 · focus · HN ↗
    mind sharing hints/links on your harness/flow setup?
    I did several attempts with naive prompting, but spent more time babysitting than actual flow
3. jorl17 · 1785965463 · focus · HN ↗
  Have been feeling the same. There's a sweet spot that threads the needle between "too dumb to search the right thing / relay the correct results" and "too smart to just stop overthinking and just report the damn thing"
4. hankbond · 1785968894 · focus · HN ↗
  Just an anecdote but thats why Deepseek v4 flash 0731 is my current favorite model. It's really not very "eager" and stays on the task at hand.
5. seahyinghang8 · 1785982147 · focus · HN ↗
  we actually have the test benchmark against luna too! it's just not in our title but you can see it in the first diagram below the title. luna does pretty well tbh but sol is just a tad bit better. but luna is way cheaper.
  if you want to dive down into the various traces of the benchmark, you can check this out: <a href="https://app.castform.com/train/a7a898f6-d802-4908-b044-acb812f14a48?tab=comp" rel="nofollow">https://app.castform.com/train/a7a898f6-d802-4908-b044-acb81...
  - founder of castform
6. seahyinghang8 · 1785982383 · focus · HN ↗
  founder of castform here again - slightly unrelated to retrieval but on the topic that folks are discussing here, i was actually collecting benchmarking various coding traces for the purpose of training a model router and surprisingly, luna held up very well against sol and terra. it was able to solve close to >95% the that sol can handle at a fraction of the cost. have not benchmarked the OSS models yet but will add the popular ones to the list like Deepseek Flash and Kimi k3 to see how they fare.
  will share the full results soon!
breadislove · 1785959360 · focus · HN ↗
On what do you guys test the model. Its very dubious that there is no common retrieval benchmark such as browsecomp plus or similar tested. And what metric do you report?
1. krm01 · 1785960775 · focus · HN ↗
  Keeping track of any AI progress is becoming harder by the day, because there's ambiguity around common/clear/consistent benchmarks. Everything is constantly skewed into favourable directions.
  1. alansaber · 1785969427 · focus · HN ↗
    TBF gaming benchmarks is not something new to AI
2. seahyinghang8 · 1785981607 · focus · HN ↗
  (founder of castform here) - we didn't get to dive too deep into the dataset we were using for the retrieval in the blogpost for brevity, but we did link the training run (which shows the dataset) here: <a href="https://app.castform.com/train/a7a898f6-d802-4908-b044-acb812f14a48?tab=comp" rel="nofollow">https://app.castform.com/train/a7a898f6-d802-4908-b044-acb81...
  the page shows the exact trace of all the models we are comparing against and the aggregate scores
  we generated the question & answer pair from gitlab product handbook (<a href="https://handbook.gitlab.com/" rel="nofollow">https://handbook.gitlab.com/) since the point is to show that you can generate training questions from raw data corpus (something a company already has today)
BedVibe_Studios · 1785961746 · focus · HN ↗
This feels like the database equivalent of "use the right data structure." We've spent two years assuming the biggest general-purpose model should do everything. It makes more sense for retrieval, reranking, reasoning, and generation to each have their own optimized model if the routing cost is negligible.
1. seahyinghang8 · 1785982994 · focus · HN ↗
  founder of castform here, we believe that as agent deployment moves from experimentation phase where cost doesn't matter as much to deployment (what's the margin of serving the request), there will be a rise in interest in optimized models.
2. nullbio · 1785998580 · focus · HN ↗
  Yes, and it's only logical things move in this direction because there's massive hardware incentive to do so. If frontier models can be broken down into small models, networks of smaller-GPUs can be utilized. Right now the smaller GPUs are basically paper weights for frontier intelligence.
dev_l1x_be · 1785963146 · focus · HN ↗
I am not sure about GPT-5.6. It usually 10x more verbose for no apparent reason than GPT-5.5. Maybe it is only me.
1. jr3592 · 1785966856 · focus · HN ↗
  Have you tried Claude? 5.6 feels less verbose, and less messy to me.
  1. dev_l1x_be · 1785968653 · focus · HN ↗
    Yeah Opus 4.8 / GPT 5.5 what I use. Fable is okish, the coding experience is a bit weird with it.
2. alansaber · 1785969391 · focus · HN ↗
  it is definitely more verbose.
3. wahnfrieden · 1785998912 · focus · HN ↗
  try adjusting model_verbosity. it defaults to verbose. and of course, use agents.md.
4. dbbk · 1786027444 · focus · HN ↗
  You can just tell it not to be verbose...
skybrian · 1785970285 · focus · HN ↗
Maybe, but a specific example showing how to do it would have been a more compelling argument.
1. kumama · 1785977131 · focus · HN ↗
  (castform founder here) we should have made it more prominent on the blogpost but here's the github repo: <a href="https://github.com/castform-ai/benchmax/tree/main/examples/neon_rag" rel="nofollow">https://github.com/castform-ai/benchmax/tree/main/examples/n...
andai · 1785976102 · focus · HN ↗
Nice, but there's no mention of how Luna or DSFlash perform on the same task? (Being 25x and 50x cheaper respectively.)
Nor of how much faster their custom model performs?
1. [deleted] · 1785976962 · focus · HN ↗
  [deleted]
2. seahyinghang8 · 1785982496 · focus · HN ↗
  we actually have the test benchmark against luna but no deepseek flash (we haven't added DSFlash into our benchmarking model pipeline)
  you can check out the full comparison against all the other models here: <a href="https://app.castform.com/train/a7a898f6-d802-4908-b044-acb812f14a48?tab=comp" rel="nofollow">https://app.castform.com/train/a7a898f6-d802-4908-b044-acb81...
  - founder of castform
cmiles8 · 1785978944 · focus · HN ↗
The big lab models are academically interesting but business wise they seem toast long term. There’s no way for these model companies to compete when the models are becoming a pure commodity and others offering options that are orders of magnitude cheaper.
It’s not that the big labs couldn’t theoretically just also put out 100x cheaper options but their business model requires them to generate huge revenues from higher priced tokens or they’ll implode.
1. kumama · 1785979924 · focus · HN ↗
  castform founder here. despite our bet on fine-tuned smaller open-source models, i'm still quite bullish on the big labs. i think scaled closed models will continue to dominate for more general purpose use-case like codegen, search, etc. but intelligence has lots of long-tail applications and i think for these longer-tail applications, finetuned custom models will rule
  1. sroussey · 1785980986 · focus · HN ↗
    Product search model:
    <a href="https://www.linkedin.com/posts/introducing-ontology-1-ugcPost-7488272626277294080-XxvU/" rel="nofollow">https://www.linkedin.com/posts/introducing-ontology-1-ugcPos...
    Edit: more direct links, sorry:
    <a href="https://onton.com/research/ontology-1" rel="nofollow">https://onton.com/research/ontology-1
    <a href="https://onton.com/research/ontology-1-benchmarks" rel="nofollow">https://onton.com/research/ontology-1-benchmarks
    kumama · 1785981193 · focus · HN ↗
    this is really cool. i'm sure some of the larger e-commerce companies are already using clickstream data to tune better query rewriters/ranking models
    podocarp · 1786009195 · focus · HN ↗
    Sorry but what is neurosymbolic model, it's not explained I think
    sroussey · 1786043427 · focus · HN ↗
    IMB YouTube video explainer:
    <a href="https://www.youtube.com/watch?v=ZfWDVO3rzeA" rel="nofollow">https://www.youtube.com/watch?v=ZfWDVO3rzeA
2. esafak · 1785983438 · focus · HN ↗
  Small models aren't going to take people's jobs. Agents using large models might. That's how their numbers make sense.
  1. cmiles8 · 1785986563 · focus · HN ↗
    Except there’s been very little evidence of this happening or about to happen, which is turning into a huge problem for the big labs.
3. typ · 1785985744 · focus · HN ↗
  Electricity becoming a commodity doesn't necessarily make nuclear reactors become commodities. And as we can see, the publication of open-weight models doesn't really diffuse the know-how of training SoAT models as we expected. Even the major cloud providers are still unable to build competitive ones from scratch on their own. That's very different than the traditional FOSS ecosystem, where everyone can copy, learn, and evolve on one's own (like, Bitcoin -> altcoins).
  On token pricing, I think it's very much bottlenecked by hardware (the aggregate of compute) rather than the number of competing models. Assuming that the ceiling of the token price is determined by the economic value a unit of compute can provide, then the less efficient ones would be priced out of the compute allocation. It's not consumers bidding up a limited number of different models, but more like tokens of different models bidding up the limited computing resource. Less-intelligent tokens (which are generated by weaker models) are crowded out by smarter tokens from the limited compute. My prediction is that we'll see a meaningful downward pressure on token prices only when the new batches of next-generation hardware get mass-deployed.
  1. podocarp · 1786008888 · focus · HN ↗
    I don't think the big companies not making Sota models being an indicator that open source failed. If all semiconductor patents expired tomorrow it would still be prohibitively difficult to manufacture your own CPU at home or at work.
    typ · 1786018565 · focus · HN ↗
    Me neither. But open weights are not open source in the first place. It wouldn't be surprising that the raw intelligence of an LLM model has little to do with the architecture (which is the part most published). The secret sauce, like how/what data gets curated and cleaned, has rarely been talked about. So, even if the labs upload their weights, competitors are very difficult, if not impossible, to replicate the technology independently.
  2. childintime · 1786026192 · focus · HN ↗
    > Electricity becoming a commodity doesn't necessarily make nuclear reactors become commodities.
    Bad comparison? Nuclear reactors become obsolete. The only reason to build a nuclear reactor is as a government vanity project, just to get the bribes you want, or weapons grade material. Dirty tech.
    LunaSea · 1786026849 · focus · HN ↗
    And you know the small benefit of having stable, large scale and low CO2 emission electricity production.
liesliy · 1785981173 · focus · HN ↗
[dead]
abratabia · 1785981717 · focus · HN ↗
[dead]
sreekanth850 · 1785984730 · focus · HN ↗
IMHO, what is broken is retrieval, the whole blind chunking which was first generation is still the default standard in RAG, this has to be changed. I'm saying this by seeing the results when we used richer parent candidates model for LLM and child segments as search probes. Even without reranking we got solid results.
modgate · 1785987278 · focus · HN ↗
[dead]
mukundzzha · 1785992465 · focus · HN ↗
[dead]
linux_devil · 1785992531 · focus · HN ↗
Why do we need to train the model to solve for retrieval within the org, so we have to keep training it whenever new dataset is introduced , or am I missing something here ?
1. jmalicki · 1785993265 · focus · HN ↗
  It's a matter of cost. Did you see the 100x cheaper?
  If you have a workload that is going to be very heavy, incurring a large training cost to make a cheaper model work well with the dataset will be dramatic cost reduction. Most large AI workloads can't afford, or truly need, the expense or capability of GPT 5.6 Sol when cheaper models can do.
  Of course you could skip that and just use GPT-5.6 Sol everywhere instead. If you're running a fast food restaurant you could hire Michelin star chefs to make your burger and fries without further training. Or you could have a training program for teenagers, a sourcing program, etc. to scale up to your chain to still get consistent quality without needing that level of cost in each store, but replacing it with a centralized repeatable process.
2. kumama · 1785994302 · focus · HN ↗
  (founder of castform here) the model you post-train should ideally learn general patterns & search strategies over your dataset that should transfer to new docs you add to the search corpus (unless its super out of distribution)
  1. srvraw · 1786006827 · focus · HN ↗
    could you share more about what you mean by "general patterns & search strategies"? I can think of it being along the lines of searching over specific tables or databases for queries in certain context. It's an exciting line of work and I'm interested because I need something like this for the problem I'm solving atm. So, I'd like to understand how the training generalizes
    kumama · 1786027497 · focus · HN ↗
    yup! it’s mostly about getting better at using the right search keywords.
    for more complex multi-hop question, it's also about knowing which sections of a document to look up and in what order.
  2. oh_no · 1786021937 · focus · HN ↗
    i'm a little confused by this, should most piles of company documentation look pretty similar? what are we getting by tuning at the org level?
    what if you have a bunch of teams or apps that have different documentation patterns?
    how much does this degrade over time, it beats leading models with that static data set but clearly this edge will degrade with data drift, how quickly does that happen?
    also, any "this is 100x cheaper" blogpost means nothing if not discussing TCO (I know your team didn't write this.) I don't care what inference costs are if I don't know training/overhead costs. what's the breakeven point. and again, how long is this RAG stack going to be worth keeping, you beat 5.6 Luna but at some point un-tuned models will beat you, so this is a temporary solution that needs to be re-upped at some point. benchmarks against data drift would help there
    kumama · 1786027103 · focus · HN ↗
    very useful questions here!
    - if you have teams that have totally different documentation patterns, yes i think a model trained one teams' docs probably won't directly transfer to another. but let's say you have a model trained on SEC 10-K filings, it should work well as new 10-K filings are added (since terminology & structure of these docs are similar) - on TCO, the training costs for the experiments you saw were <$200 - you bring up a good point on data drift, don't have concrete numbers/experiments here. something we should defn look into (though i imagine this also changes a lot based on use-case and company)
nc55g3g · 1785998891 · focus · HN ↗
[dead]
nullbio · 1785998912 · focus · HN ↗
I (and I imagine many others) would love to use something like this, but can't, because my data is too sensitive to be uploaded to a cloud of which I have no gaurantees of privacy/security.
Is there any way we do this using rented GPUs and open-source software stacks? Paying for the service isn't the issue, I don't care if it's free or if a cut is taken in some capacity, I just don't want the provider to have access to my data.
1. i5heu · 1786000576 · focus · HN ↗
  In OpenRouter there are Zero Retention options. And if you use a EU provider you can be somewhat sure that your privacy is given.
  Other than that there is not really a difference to renting a GPU since the GPU provider can also just steal your data.
  Local GPU(s) are always an option if you have the possibility. It is also not that difficult to run with stuff like “LocalAI”
2. kumama · 1786027808 · focus · HN ↗
  castform founder here. unfortunately, we are cloud-hosted at this point.
  but some easy options on the open-source side include huggingface's trl & unsloth.
  you can run our data-generation scripts here: <a href="https://github.com/castform-ai/benchmax" rel="nofollow">https://github.com/castform-ai/benchmax and then hook it up trl/unsloth for training. should be able to do all of this on your own compute.
softwaredoug · 1786016973 · focus · HN ↗
People are building agentic search one of three ways:
1. Actually good retireval. There’s been a lot of progress on serving the kinds of queries agents tend to serve, from places like Hornet, MoxedBread, LightOn. Particularly in late interaction
2. Smarter harnesses with models/judges validating the result. This is now just seen as the generator/ evaluator pattern. Here’s where people try to just use grep or some other naive retrieval system. Let the agent figure it out. But it’ll consume a lot of tokens to get good results as it iterates and loops.
3. A model trained for retrieval. Give it dumb retriever like in (2) but it is fine tuned on the task as in (1).
This article is 3. But we’ve been seeing this all year with SID.ai, Gleans Waldo model etc. if this interests you I’d check those out, particularly SID.
I wrote about these 3 approaches here <a href="https://softwaredoug.com/blog/2026/06/08/three-kinds-of-agentic-search" rel="nofollow">https://softwaredoug.com/blog/2026/06/08/three-kinds-of-agen...
1. kumama · 1786027205 · focus · HN ↗
  +1 on SID-1. we were definitely inspired by that paper
  1. maxrumpf · 1786030436 · focus · HN ↗
    SID-1 co-author here: was a lot of fun writing it. want to chat? just firstname at domain.
    kumama · 1786033354 · focus · HN ↗
    yup! email sent!
2. softwaredoug · 1786030434 · focus · HN ↗
  *MixedBread
  <a href="https://www.mixedbread.com/" rel="nofollow">https://www.mixedbread.com/
zkmon · 1786023547 · focus · HN ↗
Nice things like this, get "blue-washed" by the parent org's tech. For general adoption, kakebase should have been swapped out for a more generic non-databricks tech. 'Blue-wash' is a reference to an IBM's practice.
genshro · 1786024400 · focus · HN ↗
[dead]
oedemis · 1786024680 · focus · HN ↗
whats about self-consistency like in grpo with majority voiting?
1. kumama · 1786026656 · focus · HN ↗
  castform founder here. i'm personally a little against techniques like self-consistency/majority voting during rl training because they tend to result in the model's output distribution "sharpening" a lot. this means the model will lose it's exploration ability and probably won't be able to explore/discover new solution strategies, which can be harmful for both rl training + generalization to unseen cases
jillesvangurp · 1786025627 · focus · HN ↗
Models without tools and harnesses are not really that useful. My observation is that the tool ux is driving most progress at this point. There are of course open source tools and harnesses but they require more effort to setup properly.
The key challenge is to pick the right model for the right task or sub task and doing that automatically rather than manually. A big part of the problem here is that everybody is picking the most expensive and resource intensive models by default just in case they hit something that is a bit more difficult to get right. It's overkill. Most work people actually do is completely routine and would not have been a challenge for most of the mainstream OSS models.
I'm starting to suffer a bit from model fatigue. There are announcements almost on a daily basis about this or that new model. I can't keep up with that and I don't have time to try them out or evaluate them. I don't want to waste brain cycles on which one to use. I just want to get shit done without micromanaging AI models.
All this marketing BS and confusing naming isn't helping either. It seems a lot of that is just about tricking people into picking the expensive model so they'll burn through more tokens.
1. drob518 · 1786026541 · focus · HN ↗
  I agree with this. Interestingly, I’ve been using Deepseek v4 Flash a lot these days but I definitely have to constrain it a lot with tests. Fortunately, I can have it write the tests. It’s extremely cost effective. Still trying to figure out whether the latest update last week that made it smarter actually translates into something I can see in the output. It’s not dumber, but it’s still an open question as to whether it’s “real world smarter.”
punnerud · 1786032421 · focus · HN ↗
What’s in that “Search tool”, could actually be the same solution presented in a different way
1. kumama · 1786033431 · focus · HN ↗
  castform founder here. it uses lakebases's native bm25 and vector search and fuses the results using rrf (<a href="https://medium.com/@devalshah1619/mathematical-intuition-behind-reciprocal-rank-fusion-rrf-explained-in-2-mins-002df0cc5e2a" rel="nofollow">https://medium.com/@devalshah1619/mathematical-intuition-beh...)
2. softwaredoug · 1786034186 · focus · HN ↗
  Usually in these cases you don't need to do much tuning to the retriever. So you just give it BM25 or somesuch.
  I'm hesitant to say absolutely zero tuning, because there are cases where you do want to say, bias towards trustworthy results or recent results etc to help the model avoid wasting tokens. But probably not much beyond that.
  You can also just create a param in the tool for the agent that selects for "recent" or "popular" or "trustworthy" in ranking.
apparent · 1786037947 · focus · HN ↗
What does "100x cheaper" mean? Costs are 1 / 100? If so, is there a more appropriate term to use?
1. kumama · 1786039953 · focus · HN ↗
  cheaper in terms of token costs
adityazero · 1786041374 · focus · HN ↗
[dead]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.