Hacker News new | past | comments | ask | show | jobs | submit login
The AI boss that deploys Hong Kong's subway engineers (newscientist.com)
124 points by chrisacky on July 5, 2014 | hide | past | favorite | 37 comments



This seems like a pretty standard application of scheduling/optimization/operations research. Other applications include:

- Crew scheduling for airlines (e.g. how to satisfy union rules/minimize time-on-ground/get people back home)

- Container flow at ports

- Railway yard scheduling (e.g. allocating cars to engines)

For another example of this particular kind of work (allocating maintenance staff to projects), see a colleague's paper on work for a large gas/electric utility: http://stuff.mit.edu/people/uichanco/scheduling.html

Calling this AI is really a stretch, although the definition of AI is fairly loose I suppose. All the "smarts" are entered by humans in the form of constraints (rules, in this article), the computer's role is essentially just very efficiently searching a combinatorial search space for the best solution. Integer linear programming is a common approach for getting optimal solutions, but can require deep expertise to make fast enough. It seems in this case they have settled for heuristic solutions from a genetic algorithm - perfectly reasonable approach.

The real story for any system like this is actually getting humans to buy into it, see e.g. the many articles about the UPS ORION system for more coverage on this. The last paragraph hints at this but doesn't talk about how they got buy-in, which is something that would be really interesting.


In many ways our relationship with AI is reminiscent of the one we used to have with gods and spirits. Thanks to the AI Effect, one day, we will be able to point to each aspect of intelligence and find that actually, it's just some banal algorithm used by Walmart operations departments. After which, we will be forced to conclude that Intelligence does not exist or worse, face something fearsome indeed.

More seriously, your point is common and valid. My own belief however, is that whatever it is that underlies our ability; it will be some mish of deduction, abduction, optimization and search. The application of search/optimization towards the fulfillment of some goal should count as intelligence. But I understand why this view might not (yet) be widely held. http://en.wikipedia.org/wiki/AI_effect


> conclude that Intelligence does not exist

You are going about it backwards. Intelligence obviously does exist, yet when we try to figure out what makes it tick each step seems banal.

Your conclusion is that intelligence might not exist, mine is that defining intelligence by the parts that make it up is incorrect. Intelligence is some sort of super-process that is not so easy to break down.

It's like how we share 98% of DNA with an ape - so clearly there is only a 2% difference. Except not. There is a huge difference, an unmeasurable difference, which means that classifying DNA by percent similarity in base pairs is an incorrect approach.


I see this as an extrapolation of an expert system, which is an AI. It seems the more you know about how they work, the less they seem like artificial intelligence and more like some simple optimization problem. I suppose this is what the Chinese Room (http://en.wikipedia.org/wiki/Chinese_room) is all about.


I don't think it truly qualifies as an expert system because, to the best I can determine from this limited article, it doesn't make any inferences from a base set of rules. Rather, it is provided with a comprehensive set of all rules, and attempts to find the best solution that satisfy those rules (or, in the language of operations research, constraints). The value provided then is that, because it can consider the space of solutions efficiently, it may discover solutions which are not obvious to human operators.

The way these systems are made, and as the article mentions, is that the obvious rules are added, and solutions evaluated. Experience humans will then usually discover something about the solution that is impossible/impractical, but was not included in the provided rules. The new rules/constraints, and the process repeats until humans are comfortable with the feasibility of the solution/schedule.


That's a good point. This system is more of a constraint solver than an expert system. It's not really answering questions than optimizing one (big and dynamic) scheduling problem.


I feel the same way about machine learning algorithms and even deep learning. The more you learn about how the algorithms work, the more it seems like just simple averaging of numbers. I think this is a good thing though, because it removes the mysticism behind it.


The term of ai is missleading. There are a lotts of different concepts people associate with ai. Classical ai is just some search for the optimal solution in the state space, often represented as a tree. However ai in common sense refers to a system that figures stuff out by it self using supervised, unsupervised or reinforcement learning.


This really reminds me of an essay called "Manna" from Marshall Brain (which may already be known to a large number of HN readers).

[1] http://marshallbrain.com/manna1.htm

[2] https://en.wikipedia.org/wiki/Manna_(novel)


Definitely (if in need of an editor).


SISCOG [1] is a company that has been developing such systems for quite some time now (since 1986).

In their case I know that the core of their systems is written in LISP and it's mostly AI optimizaiton algorithms. The guys who run the company are both professors of AI related classes in the CS dept of IST.UTL.PT.

[1]: http://siscog.pt/


http://biarri.com too. They use c++ and python I think, and a few of the guys there lecture at the University of Queensland.

I don't think this sort of scheduling optimisation is as unique as the OP makes out.


>>But the people that had to carry out the scheduled work took a while to get used to the idea, as they didn't like not knowing why they were doing certain things.

There's some real Asimovesque worship of technology here. Without sounding like a Luddite (computers are good at scheduling), this is scientifically scary.


> Strike the first rune upon the engine's casing employing the chosen wrench. Its tip should be anointed with the oil of engineering using the proper incantation when the auspices are correct. Strike the second rune upon the engine's casing employing the arc-tip of the power-driver. If the second rune is not good, a third rune may be struck in like manner to the first. This is done according to the true ritual laid down by Scotti the Enginseer. A libation should be offered. If this sequence is properly observed the engines may be brought to full activation by depressing the large panel marked "ON".


Post apocalyptic technology worship: A Canticle for Leibowitz by Walter Miller :)

The world needs more of this stuff.


Not really. The article isn't very clear on the point, but the workers always know why they're performing task X--let's say, replacing damaged track X--because the reason is the same as before. That's never changed. What they're apparently confused about is the prioritization of task X over task Y because "the machine" is now involved. It's not a case of being told to bang a wrench against a pipe in a random tunnel and then wondering why.

In a lot of ways, it's not that dissimilar than it was before. Why did their supervisors prioritize one task over the other in the past? It's the same thing, only now, it's a more objective algorithm that's handling the tasking. Assuaging these fears (if that's the right word) is almost a non-issue in this context as even the most basic of explanations can solve the problem. I fail to understand how this could be interpreted as scary. Might you elaborate a bit?


I don't know. It's not worship if it actually works better for reasons that are understandable. I see it more as a fear of new things, all too common in every industry.


Sounds more like a classic optimization model (operations research) than like an AI model. Great case study though. I wonder why they used a GA and custom stuff instead of off the shelf software from gurobi or IBM OPL etc.


For scheduling problems, I have had way more luck with open source CP solvers like Choco than I have had with hyper-optimized commercial IP solvers like gurobi. Branch and Cut is just too indirect for constraint heavy IP models.


"Nurse scheduling competitions" seem to alternate between IP and CP approaches - my feeling is that when the number of solutions is "small", CP pulls ahead, but when there are many solutions and the objective is important, IP wins. Very case-by-case dependent, regardless.


I've found that size doesn't matter much at all...but constraint type does (hard vs soft). Soft constraints very easily lend themselves to IP formulations, but problems with lots of hard constraints require a ton of luck to get it to work quickly with an IP solver. 3d bin packing, for example, is very heavy on hard constraints. I have a CP model (using the Geost constraint primarily) with an ensemble search heuristic (genetic + LNS), and I have yet to find an IP model that can get within 2 orders of magnitude of the average solve times of the CP model.


Out of curiosity, how does the off-the-shelf software solve scheduling problems? EDIT: Nevermind, another comment pointed out integer programming


From the article, it doesn't sound like any actual artificial intelligence or machine learning techniques are being applied here, just a collection of algorithms. Does anyone know technical details?


They said it's a genetic algorithm, which just means they're looking for an approximate solution to an NP complete problem. My guess is that they have a list of tasks and dependencies, and then try to do the tasks in an order that minimizes conflicting use of dependencies. An example being track section A requires signal work and track work. section B requires track work. Do the signal work on section A and the track work on section B, then do the track work on section B. This is better than doing the track work on section A and letting section B remain idle.

Of course, with hundreds of miles of track and thousands of tasks to perform, the algorithm does a better job than people. Though people are not particularly bad at this task.


I also suspect this is a "defensive" move. A good experienced co-ordinate will give a ML system a run for its money on "gut" plus be able to factor in the efficiency of certain teams, morale and even how hard the "track work" is - but he gets it wrong and it was "gut" and his boss cannot justify it. Put in an ML system and his boss now gets to say "the system decided"

Both ways there is an expected % of sub optimal decisions but only one can the boss blame someone else.


Thing is, computers are really better at such tasks when the number of constraints grow too much for human to handle (i.e. beyond a few). It's because in time the human expert is able to articulate the solution he just thought of, the computer will search 100 000 other points in solution space and likely find a better one.


But ... Only if a programmer has coded the other solution into the algorithm OR if the ML is able to distinguish between a correlation and a causation.

Before Looking for Black Swans look for Xmas Turkey's.


> if the ML is able to distinguish between a correlation and a causation

Of course it is. You can get the causation structure out of a correlative dataset with some basic Bayesian math.

http://lesswrong.com/lw/ev3/causal_diagrams_and_causal_model...


Well, "gut" is far from obsolete, but not everything requires "gut".

The article claims the program performs better when compared to data from manual management. It'll be saving them $800k/year alone. Also since the program will be evolving over time, you can assume there are still people monitoring its performance and feeding that back into the loop.

Similar scheduling algorithms are already in use all over the world. If you're a student, chances are your program is made by a computer "boss" too. Scheduling is not the kind of chore humans are best at.

We don't have to be cynical and suspect ulterior motives. After all, we created computers to be our assistants, and here we go, they are. And it's good. Every win for computers is a win for people.


'machine learning techniques' are just algorithms that you can get extra money for


This is quite an exciting change from the usual government bungling (the MTR is 75% owned by the government)

I'd like to see some of this technology make its way out the MTR and invigorate HK tech in general.


This posted not too long ago. https://news.ycombinator.com/item?id=7992109

Got no traction though.


Does anyone know how these things are deployed in real life/production ? I know of Choco as a solver, but have only used it in commandline programs.

Does this kind of a system manifest itself as a webapp or as a dedicated Windows box with a GUI. Are the "machine readable rules" merely saved in the database - does anyone know how these look like in terms of schema ?


Reminds me of this well-written short story (part 1): http://marshallbrain.com/manna1.htm


My first thought was, "Primordia?"

But really, I think the term AI is a bit much here.


This article gives an example of which are the easiest jobs to replace by AI/programs : middle management. Any manager that merely manages a few people and doesn't take responsibility for any business function ... that's what's getting replaced first.

Tbh, I won't miss these guys at all.

On the other hand, this is the future. You want to talk to your boss ? Well he has 500 reports, so "press 1 to ask for a day off". I do believe they have the potential to be much more flexible than any human though. Of course that's going to be exploited in favor of businesses.

But if my job was essentially to pass on information from management to individual contributors, I'd be very worried.


If your job is essentially to pass on information from management to individual contributors, then irrespective of your title, you are not "middle management", you're a secretary.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: