Why?
Why?
the claim is extraordinary, yet the answers cover only the mundane.
I wonder how many of these posts are astroturfed.
The sum of people not even close to the topic has risen, according to my feels at least.
Has this rang true for anyone else?
For decision-making with neural networks, we instead need the older idea of estimators of the predictive uncertainty with constraints in the feature-representation space (over training/support of the estimator), as with Similarity-Distance-Magnitude estimators: https://pypi.org/project/reexpress-sdm/
Like just tuning this model can make it cheaper for voice AI providers to do semantic turn detection over the space of responses.
System one models do not have an obvious use in voice ai, unless you are choosing from a list of potential utterances (eg embed -> top k -> choose from top k)
Modern stt is baking semantic EOT into the prediction. It makes sense. Conversation has many potential ends, and you have to deal with misprediction of current words that may signal completion, but mel spectrograms contain a ton of information as well.
In your version, we’d have to deal with partial transcriptions and a system that is not natively audio aware. It would also be much more expensive.
I haven't personally yet found a net-new-capability bigger than that from LLMs here.
These guys also love text to sql. I know 4 people each implementing text to sql for their separate companies. Or text-to-redash dashboard in some cases. Funnily enough, text to sql is one of the things where LLMs are clearly sub-human. Mostly due to lack of easy verifiability.
Text to SQL is a really bad idea, as the agent will just generate really convincing and terrible analyses that lack all business context.
I mean, you could implement some kind of semantic layer, but that's a lot of work, for uncertain reward.
I saw a place which essentially tasked the data analysts/scientists in an area to describe the good tables, and assumptions and necessary context to make decent queries/analyses, and that definitely lead to much, much better (almost usable) results.
As I have said many times, what the world really needs is SQL2Text, rather than Text2SQL.
Yep. After this has been done, the later text to sql outputs works half decent. The major issue I heard was that whenever a small assumption changes few months down the line, while humans are able to "JIT" apply it to each of their queries, these models sometimes lose it in all of the context and so it becomes hard to progressively update anything - you end up having to redo the whole workflow.
And in my experience, even the more complex dashboards requested by product or upper mgmt were stood up within the day by humans. Or the next day (but that was cos some ETL would be scheduled overnight rather than immediately). And I am not sure if speeding up this part would even matter to the guy who requested the dashboard. So I am not sure if this is a major bottleneck people should try to innovate in. If openai does the work for you then great but otherwise. Humans aided by copilot-of-old style autocomplete is probably more than enough.
Needless to say, text to sql is pointless for application queries made during API calls.
The whole text to SQL thing is about data teams being a bottleneck to the business (rather like software people). The goal is good in theory but honestly an Excel plugin is probably a better solution in many cases.
There are a lot of those types of problems in the world, replacing what was previously spotty hardcoded decision logic that worked 70% of the time with something that now gets it right 95% of the time. Even if not perfect, the fact that you can dramatically close the gap means a lot lower cost overall, so it’s worth it.
But you're right that more complex solutions are still a bit elusive. I use a bot to plan my strength workouts based on my soreness level and what equipment I have available and it's decent, but not perfect.