353 karma · joined September 20, 2010
what do ttft numbers look like for mercury 2? I can see how at least compared to other reasoning models it could improve things quite a bit but i'm wondering if it really makes reasoning viable in voice given it seems total latency is still in single digit seconds, not hundreds of milliseconds
For instance, when the cost of building a new (good) app goes to zero, it becomes economical to make a great app for a narrow niche, with a skeleton staff (maybe just one) and no VC money. And this can happen thousands of times over.
Robotics could open up bespoke local supply chains even beyond what's possible with a 3D printer today. For instance, if you had an actually dextrous humanoid robot "living" in your home, why wouldn't you have it just make all of your clothes? You could have any fabric, any style, exactly the right size. And only for the cost of materials (assuming you already own or lease the robot itself).
I do think the author is right in the big picture - the future will be more fun.
1. the farmer's almanac i thought of when i saw the title and even read the article is not going anywhere 2. i have never before heard of the farmer's almanac referred to in this notice
But it's only an incremental improvement over the existing o line. So people feel like the improvement from the current OpenAI SoTA isn't there to justify a whole bump. They probably should have just called o1 GPT-5 last year.
- Michelangelo
Chat is an awesome powerup for any serious tool you already have, so long as the entity on the other side of the chat has the agency to actually manipulate the tool alongside you as well.
They don't really describe what "success" would look like but it seems to me like the primary goal is to minimize "incorrect", rather than to maximize "correct". the mini models would get there by maximizing "not attempted" with the larger models having much higher "correct". Then both model sizes could hopefully reach 90%+ "correct" when given access to external lookup tools.
1. chunk the corpus of data (various strategies but they're all somewhat intuitive)
2. compute embedding for each chunk
3. generate search query/queries
4. compute embedding for each query
5. rank corpus chunks by distance to query (vector search)
6. construct return values (e.g chunk + surrounding context, or whole doc, etc)
So this article really gets at the importance of a hidden, relatively mundane-feeling, operation that occurs which can have an outsized impact on the performance of the system. I do wish it had more concrete recommendations in the last section and code sample of a robust project with normalization, fine-tuning, and eval.
outputs are sent in text + audio but you'll get the text very quickly and audio a bit slower, and of course the audio takes time to play back. the text also doesn't currently have timing cues so its up to you if you want to try to play it "in sync". if the user interrupts the audio, you need to send back a truncation event so it can roll its own context back, and if you never presented the text to the user you'll need to truncate it there as well to ensure your storage isn't polluted with fragments the user never heard.
(and whatever the opposite of "click bait" is, that's how I'd describe the original title!)
The new symbols aren't any better but the UX of "push this button to turn on or off" combined with obvious lights/etc when something is on has mostly made the semantic meaning of the symbols obsolete to 99% of consumers.