hhdhdbdb
Depends why they are losing money. But losing money alone is not bad. This ain't an ice cream truck.
Agree groq implodes if demand for intellegent automation tanks (i.e. bubble burst), or competitors disrupt the disruptor. Another Z is all you need paper means my old laptop is running models fast or something means groq is not something you need.
They can probably pivot.
BTW OpenAI is 9 years old and they are a SaaS/PaaS running on Azure.
They say: Tesla shares up as revealations surface that the wind is blowing east.
Edit: I will add Apple.
If it worked I wonder if it worked as a shibboleth.
2. Ask for more money and/or more shares (if you think the shares are any good).
There is a tiny chance that asking for 133700 might get a smile at a smaller tech focused company though.
The only hope is to generate this power greenly.
Chain of thought type operations is in this "niche".
Also anything where the value is in the follow up chat not the one shot.
In this case, how does the fact that a big object is still influencing space/time around it communicate that fact when it is not moving. Is that still gravitrons?
It is too big to evem worry about that 4k a day clicks for one site. It is like us optimizing the expense of 0.01c. It makes a difference when that 0.01c is an API call that you call a million times. But it only surfaces if you do aggregate it.
Therefore this problem can only even be seem by Google if it can be surfaced in aggregate overy say a billion queries.
I wonder how that can be done.
Probably only can be done using data. Which means spying on people in various ways. And making assumptions about length of time on site equals quality.
They probably use machine learning too. There may be no reason for the lost rankings other than a wind change caused by some updated parameters in an OKR chasing model.
Eg find out what my neighbours have installed.
Or if the data before an SSH key is predictable, keep writing that out to disk guessing the next byte or something like that.
I agree not to fail on insert too by the way. The insert is sort of an enqueuing action.
I was debating if a microservice should process that queue.
Since you are a PaaS the distinction might be almost moot. An implementation detail. (It would affect the api though).
However if Postgres added this feature generally it would seem odd to me because it feels like the DB doing app stuff. The DB is fetching data for itself from an external source.
The advantage is it is one less thing for the app to do and maybe deals with errands many teams have to roll their own code for.
A downside is if I want to change how this is done I probably can't. Say I have data residency or securiry requirements that affect the data I want to encode.
I think there is much to consider. Probably the why not both meme applies though. Use the built in feature if you can, and roll your own where you can't.
LLM takes my job then we have reached the singularity. Jobs wont matter anymore at that point.
It is certainly convenient for the end user, but it hides things. What if the API calls to open AI fail or get rate limited. How is that surfaced. Will I see that in my observability. Will queries just silently miss results.
If the DB does the embedding itself synchronously within the write it would make sense. That would be more like elastic search or a typical full text index.
I say that because it seems n unsual. Index would suit sync better. But async things like embeddings, geo for an address, is this email considered a spammer etc. feel like app level stuff.