3 ms·

I don't think that's your real objection: consider a chat-bot, perhaps doing tech support, that can only output one letter at a time (forming words over multipl

by tgb 11y ago

I don't think that's your real objection: consider a chat-bot, perhaps doing tech support, that can only output one letter at a time (forming words over multiple outputs). It chooses from one of 26 or so options at each step. State space is finite. You still think that GO is fundamentally unlike this case, but not for the reasons that you've presented.

daveguy 11y ago
A chatbot is definitely not choosing each letter separately. It is not even choosing each word separately. It is likely choosing a phrase structure and populating with a fixed set of words. LSTM net may be going word for word, but letter for letter would give poor results. At the very least you need n-grams.
- tgb 11y ago
  You can write a chatbot which DOES choose each letter separately and it's isomorphic to the one which does not. This was part of my complaint about the branching factor discussion from an earlier article: it's not really well-defined. Your comment is like saying that AlphaGO doesn't choose each move separately, it considers a sequence of moves. Of course it does, but it still can output each move one at a time.
  - daveguy 11y ago
    No, my comment is like saying the typical minimum selection and output chunk of a chatbot is greater than one character at a time. The rules of Go dictate a single position selection per move. Chatbots do not have that restriction. Yes you can write a chatbot that chooses a character at a time, but no chatbot using a per character chunk has been considered remotely successful since before Eliza. I agree that the branching factor is not well defined for a chatbot. Although it definitely is not 26.
    - tgb 11y ago
      I'm saying that you can write it that way AND have no loss of functionality or infact any apparent change from the perspective of the user. Take a chat bot and have it output characters one at a time. That's all I'm claiming, nothing about how the chatbot decides what to output. But that suffices to show that a process which is choosing from a very constrained set of options is still in a different class of success than AlphaGo. The options chosen at each step are more constrained than the choice of moves in Go, so the argument "the difference between solving go and solving tech support is the number of options available at any time" is insufficient. One might be able to define a better notion than branching factor that takes into account how many steps are needed as well as how much it branches in each step and such a thing is probably much larger for tech support than it is for go. But such an argument would be hard to state well, I think.

by tgb 11y ago

daveguy 11y ago

A chatbot is definitely not choosing each letter separately. It is not even choosing each word separately. It is likely choosing a phrase structure and populating with a fixed set of words. LSTM net may be going word for word, but letter for letter would give poor results. At the very least you need n-grams.

tgb 11y ago
You can write a chatbot which DOES choose each letter separately and it's isomorphic to the one which does not. This was part of my complaint about the branching factor discussion from an earlier article: it's not really well-defined. Your comment is like saying that AlphaGO doesn't choose each move separately, it considers a sequence of moves. Of course it does, but it still can output each move one at a time.
- daveguy 11y ago
  No, my comment is like saying the typical minimum selection and output chunk of a chatbot is greater than one character at a time. The rules of Go dictate a single position selection per move. Chatbots do not have that restriction. Yes you can write a chatbot that chooses a character at a time, but no chatbot using a per character chunk has been considered remotely successful since before Eliza. I agree that the branching factor is not well defined for a chatbot. Although it definitely is not 26.
  - tgb 11y ago
    I'm saying that you can write it that way AND have no loss of functionality or infact any apparent change from the perspective of the user. Take a chat bot and have it output characters one at a time. That's all I'm claiming, nothing about how the chatbot decides what to output. But that suffices to show that a process which is choosing from a very constrained set of options is still in a different class of success than AlphaGo. The options chosen at each step are more constrained than the choice of moves in Go, so the argument "the difference between solving go and solving tech support is the number of options available at any time" is insufficient. One might be able to define a better notion than branching factor that takes into account how many steps are needed as well as how much it branches in each step and such a thing is probably much larger for tech support than it is for go. But such an argument would be hard to state well, I think.