3 ms·
* level 1 — command & response Functions? * level 2 — hard-coded conversation flows Scripts? * level 3 — fuzzy/continuous/fluid state. Threading? I can't
by lfowles 11y ago
* level 1 — command & response
Functions?
* level 2 — hard-coded conversation flows
Scripts?
* level 3 — fuzzy/continuous/fluid state.
Threading?
I can't shake the feeling that deep learning is being shoehorned into a bot with a specific purpose (ShoeBot, etc). Talking to a ShoeBot, I would expect it to have predictable responses or state changes. I don't want it to suddenly infer that I'm looking for shoes for my wife because of an opaque model it's formed from an insufficient set of training data. Many applications of deep learning seem to be just a lazy way to have the machines do the work automagically.
- Mtinie 11y ago> I don't want it to suddenly infer that I'm looking for shoes for my wife... If the end goal is a human-like level of conversation, isn't this a desirable outcome? Inference and allusion are two elements that are used all the time during conversations between people -- with positive and negative consequences. I guess it depends on the ultimate outcome you are seeking from the conversation.
- lfowles 11y agoUltimate outcome is that I want to buy a good pair of shoes for myself :) I'm not particularly interested in the conversation unless the bot happened to be a domain expert (I find it unlikely that there is enough training data available to make it a credible domain expert..). The point was that I'm especially wary of its internal state incorrectly transitioning but now no one knows why due to the deep learning implementation.
- Mtinie 11y agoFair point, especially if the bot becomes biased in some way after that point and fails to adapt to your cues ("no, these shoes are for me, not my wife..").
- kastnerkyle 11y agoAs you say, if your only goal is ShoeBot this (scripts, functions, etc.) is a great way to go. One of the key points of deep learning approaches is that you have this abstract, powerful computational device that is trained to extract the necessary features and also perform the task jointly - and it just happens to be a ShoeBot due to the training data. This usually results in improved performance along with "ease of use" in transitioning to new but related applications. A model just happens to be a ShoeBot when trained on specific data, but ostensibly a person or company could make ShoeBot, CarBot, ApartmentBot, etc with the exact same approach, given enough data. This is very different than a workflow of "craft tons of features for domain X, write custom scripts/conversation logic for domain X, etc.". These choices between feature based approaches and "deep" techniques are tradeoffs reminiscent of "you aren't gonna need it" versus "room to scale", but in the ML algorithms you choose rather than the software stack/implementation. It depends on things like how much data you have, how much compute you are willing to pay for, how many users you expect, and so on - but neither approach is necessarily wrong. In general if deep learning approaches don't roundly beat feature engineered or hand crafted approaches, you don't have enough data or are trying to shoehorn (pardon the pun) a solution that doesn't fit. Right tool for the job and all that.
- lfowles 11y agoLike Google Photos, this might just be something I have to see to believe. However... Google Photos routinely categorizes pictures of my dog as Bear or Cat. My greatest concern is about being able to acquire the conversations necessary to train these niche applications beyond a laughable state.