2 ms·

> That doesn't take an LLM to accomplish, I don't think. After all, a car has a limited number of functions. It should be mostly a matter of broadening the voic

by rlpb 9mo ago

> That doesn't take an LLM to accomplish, I don't think. After all, a car has a limited number of functions. It should be mostly a matter of broadening the voice recognition dictionary and expanding the fixed logic to deal with that breadth. I think the most effective way to get this accurate and effective is to give an LLM the user’s voice prompt and current context and ask to convert the user’s request into an API call. The user wouldn’t be chatting with the LLM directly. The point is that it doesn’t require a static dictionary to already have your exact phrasing and will just work with plain English.

ssl-3 9mo ago
That requires either an online connection to a datacenter somewhere or something that (at present time) is a fairly substantial on-board computing system, and those are things that I think are worth trying to avoid for tasks like adjusting the HVAC in a Honda. Maybe some day. Right now, when we do have substantial on-board computing systems, they're trying to drive the car -- not change the temperature. Adding in an additional computational timeslot for LLM voice commands seems both foolhardy and expensive. Meanwhile: Broader dictionaries and static flows with greater breadth for voice recognition? We can do that right now. (We can even use LLMs to help generate the static flows, along with people to evaluate and test them. Once implemented, they become cheap to run. This is in-keeping with a fairly common theme here on HN: Don't use the bot to process the data. Instead, use the bot to write the data processor.)