Shulou(Shulou.com)06/02 Report--

It is not easy to do one thing, but the pit is always there.

Dr. Bao Jie clicked on the big pit and small pit of the artificial intelligence project in the online talk of Jiangmen Venture Capital on May 10, and selected ten classic pits that looked very contrary to common sense.

This is a collection of truths, but don't despair, you will finally release the eggs summed up from the experience of stepping on the pit in the past 20 years.

Introduction to the author

Dr. Bao Jie, Wen Yin connected CEO. Has 20 years of relevant experience in academia and industry. Doctor of artificial Intelligence of Iowa State University, postdoctoral fellow of RPI, visiting researcher of MIT, member of W3C OWL (Web Ontology language) working Group, former researcher of Samsung American R & D Center, and core designer of Samsung question and answer system SVoice. The main research fields cover many branches of artificial intelligence, including machine learning, neural networks, data mining, natural language processing, formal reasoning, semantic web and ontology engineering, and more than 70 related papers have been published. He is a member of the Special Committee on language and knowledge Computing of the Chinese Information Society, the editorial board of the Journal of the China computer Association, and a representative of the W3C Advisory member. Since 2010, we have focused on the research and application of financial intelligence. The achievements include XBRL semantic model, fundamental analysis based on knowledge graph, financial question and answer engine, automatic extraction of financial reports, automatic supervision and so on.

The following is the original speech:

Dr. Bao Jie: my topic today is "Ten ways to make sure you screw up an artificial intelligence project". According to these ten methods, you can basically screw up a project. (laughs)

I can talk about this topic because I have screwed up a lot of projects myself, and more than half of the projects in the following list failed in the end:

I began to think, why can't most of the projects be done in the end?

I have experienced several painful times, such as being a postdoctoral student at RPI, which has the best knowledge graph laboratory in the United States. James Hendler and Deborah Mcguinness in the lab are the best teachers in this field.

I made a knowledge management system there, and in my opinion, we are the best semantic web laboratory in the world and the most professional group of people, and it doesn't seem reasonable not to use this technology to arm ourselves, so I built a semantic retrieval system, but no one used it later.

I'm just thinking about what the problem is, and why the best experts in the industry make such a system that they don't even have to use themselves.

I keep thinking, what are the core reasons for the failure of artificial intelligence projects?

Of course, there were more failures later. Based on these experiences of direct or indirect failure, I gradually summed up some of the reasons to ensure that a project will fail. Many of these reasons seem counterintuitive, and I will tell you one by one.

In the end, I will also summarize what should be done if you want to avoid these 10 pits.

NO.1 spent a lot of money at once.

The first way to make sure your project fails: spend a lot of money at once.

I am also starting a business, and a VC asked me, "what you are doing, if BAT spends a lot of money, will it catch up with you all at once?"

I say no, and the usual example is the Japanese fifth-generation machine. At the beginning, Japan made a national effort and spent tens of billions of yen, but it was not done in the end.

What is the fifth generation machine? The late 1970s was the first time that artificial intelligence began to pick up in winter. The 1980s began to enter the second peak of artificial intelligence. At this time, Japan launched a new project called the fifth generation computer.

What is the fifth generation computer? The first four generations of computers were tubes, transistors, integrated circuits, and large-scale integrated circuits. When Japan reached the fifth generation of computers, they thought that if they wanted to do artificial intelligence, they must use the proprietary hardware of artificial intelligence.

(the concept map of the fifth generation computer system in the Challenge of knowledge and Information processing Systems: a preliminary report on the Fifth Generation computer system)

Does that sound familiar? Recently, when I was doing deep learning, I saw a lot of ideas about deep learning chips. This idea is not new, because 30 years ago, the Japanese already had this idea in the computing of the fifth generation machine, but the artificial intelligence chip at that time was not the chip of deep learning now, but the chip of Prolog.

Prolog is a language of artificial intelligence, mainly a logical modeling language. If you can use Prolog to build a computer, the computer can think and handle a variety of cognitive tasks. This is a very large national project, which finally cost tens of billions of yen, spent 10 years, and finally failed victoriously in 1992.

This is not the only case. Many large projects have failed in the end.

Why did you fail when you spent a lot of money at first? If you want to do a project, there is usually a goal. When you have a large budget, your goals are usually high. For example, the goal of the fifth generation machine could not be achieved not only at that time, but also today, 30 years later.

Although the fifth-generation machine failed, the Japanese artificial intelligence technology has been greatly improved in the research and development of the fifth-generation machine, so 20 years later, when the semantic Web rose, the research level of the semantic Web in Japan was still quite good. The money was not wasted, and it trained a lot of talents.

While making fifth-generation machines in Japan, there are similar studies in the United States, mainly that LISP machine,LISP is another language of artificial intelligence and a language for logical modeling. One of the companies is called think machine. There were at least 100 LISP companies at that time.

Why mention think machine separately? The founder was silent for a while after the failure, and started a new company called MetaWeb,MetaWeb, which was founded in 2005. The company has a product called Freebase, which uses Wikipedia as a good knowledge base.

The company was acquired by Google in 2010 and renamed Google knowledge Graph. So today Google's knowledge graph has a lot of history, which can be traced back to the research of LISP machine 30 years ago.

Rome was not built in a day, so spending a lot of money at once will lead to too high the goal of the project, resulting in a high probability of failure of the project.

I once met a man from a large state-owned enterprise who told me that they would spend 30 million yuan to build an internal knowledge management system. I asked him, how did you vote for that 30 million? He said I was going to invest 30 million in my first year. Then I didn't say anything because my idea was that the project was bound to fail. Later, the project really failed.

There are also some big companies that invest a lot more money on AI projects. None of this necessarily makes things easier to succeed.

This is the first way to spend a lot of money at once.

NO.2 decides the technical route based on the latest paper.

The second way: to determine the technical route according to the latest papers, which may also be contrary to common sense.

Because the latest technology is not the best technology, it should be noted that in the field of engineering, there are usually practical constraints to solve problems. The paper is a kind of laboratory environment, which is different.

For example, in the laboratory, we can assume that there is some data, we can assume that the data has been integrated, cleaned, and there is no noise. It can be assumed that the goal is clear, but none of these assumptions are necessarily true in reality.

The best example is information extraction, which is an article on EMNLP in 2013, which I pulled out.

This diagram tells us how the NLP paper differs from the technical route adopted in the actual industrial system.

From 2003 to 2012, in the entity extraction sub-field of natural language processing papers published in academia, 75% were papers based on machine learning, 21% were papers based on mixed machine learning and rule-based methods, and only 1% were papers using rule-based methods, a very low proportion. But when we saw the practical application in industry, we found a completely different proportion distribution of technology, with 45% of them using rule-based methods.

If you just look at large vendors, such as companies like IBM, 67% of the software is based entirely on a rule-based approach. Software based entirely on statistical methods, the machine learning method, accounts for 33% of all suppliers and only 17% of large suppliers.

So there is a huge difference from academic research to industrial practice. Why is there such a difference? As I just mentioned, when publishing a paper, there is no need to consider the constraints that will be encountered in reality. In the field of knowledge extraction and entity extraction, although theoretically, it has been solved, such as entity recognition problem, NER problem, word segmentation problem, but in the real corpus, it is found that these methods are not easy to use. This can also be verified by another question, which is the question and answer system.

Today, I see most of the papers-- I don't do accurate statistics, but based on fuzzy views-- I can see that most of the published papers in the question and answer system are based on statistical methods. In particular, the NLP-based approach in the past two years, especially the end-to-end approach. Without exception, the question answering system that can be really used in industry, except for the chatting system such as Xiao Bing, the real task-oriented question answering system is all based on the rule system. I don't know which one is used for deep learning, of course, it may also be used in a specific detail, or a component, I have not seen it used in the overall architecture.

Therefore, when determining the technical route of an engineering problem, it is not necessary to do it according to the latest paper trend, and even the paper is not necessarily related to the technology ten years later. The technical route must be determined according to the actual situation and the constraints of the reality.

NO.3 deviates from the real application scenario

The third approach: if you deviate from the real application scenario, the project is doomed to failure.

Here I use OWL2 to explain. OWL2 is a language, which is familiar to the students who do the semantic Web.

All of these standardized formats known on Web, such as HTML, are designed by the W3C, the World wide Web Consortium. The World wide Web Consortium is also responsible for other protocols on Web, one of which is called OWL. It's about how to express our knowledge on the Internet.

For example, if a restaurant wants to publish its menu, what format should be used to publish it? Or I'm going to post my resume online now, hoping to be better retrieved by Google. I want to tell Google that I am a person, what is my last name, what is my first name, what is the date of birth, and what format should I use to publish such data. One of the formats is OWL. The first version of OWL was released in 2004 and the second in 2010.

Among the members of OWL WORKING GROUP's more active working group are quite a number of teachers from well-known universities, as well as scientists from well-known companies, including IBM, Oracle and Hewlett-Packard. You notice that when I mentioned these big companies, there were some names that didn't appear, such as Google and Facebook.

What OWL2 wanted to do was to design how to express and publish information about daily life online. However, in the end, the composition of the working group, one is university researchers, and the other is large companies doing enterprise applications, most of which are far away from the scene.

The final product, the OWL2 language, deviates from the scenario where you really want to serve. OWL WORKING GROUP wrote about dozens of application cases during the meeting, but most of the cases are like this: if a pharmaceutical company wants to make a drug, how to express pharmaceutical knowledge, or how a doctor expresses medical records, diseases, or genes. Not a single case is about how to find a friend online, or how to chat with a friend, or how to order a meal. There are no cases in daily life.

When OWL2 is finally written, it has 600 pages, which is a very complex language. In fact, it is used in a small number of enterprise applications, and there are few successful cases in real day-to-day applications. This is a typical project that is out of the application scenario, so the project, which spent a lot of money, didn't achieve what it really wanted to achieve.

NO.4 uses an overly leading architecture

The fourth approach is to use an architecture that is too advanced.

This also echoes the previous second method, which says that you can't determine your technical route based on the latest paper. The fourth method is to say that if you use a particularly advanced architecture, it may cause your project to fail.

Twine was called the first large-scale semantic Web application in the world in 2007. At that time, it was a star enterprise, and the company closed down in 2010. Why? When Twine was founded, it wanted to do an application of semantic bookmarking. For example, I read an article and I think it's good. Save it and read it later. Twine's robot will analyze what is being said in the article I saved and give it a semantic tag. If someone subscribes to my tag, he can keep seeing the good things under my tag, that's all.

Twine uses a new database called RDF at the bottom. RDF is a semantic Web language that is much more powerful than relational databases. It is a database that can be inferred. But when the number of Twine users reaches 2 million, it encounters a bottleneck and the performance of the database is not enough. So Twine's CEO decided to develop a new database.

At that time, the company had about 40 people and 20 people to develop the basics-- a new semantic database. In 2008, things went well, and they found that what they made was a very good thing, and suddenly they were thinking, why do we only search for bookmarks? It's perfectly possible to search the entire Web. So they made a transformation to do the semantic search of the entire Web. The company was dragged to death by taking too long a step. When the economic crisis broke out in 2008, the capital chain broke and died after a year.

At the time of his death, Twine's CEO Nova Spivack was a very respectable forerunner in our field, a technologist, and a very successful investor. He reviewed the failure of Twine. He said that I tried to innovate in too many places, that I should either innovate a platform, an application, or a business model, but I seemed to innovate in too many places, and I used a very advanced architecture, the RDF database, which led me to pursue a goal that was too big for me to achieve.

I think what he said, even today, is worth thinking about.

I read the analytical articles related to this project almost every two years. After the failure of Twine, Nova Spivack transformed the company and set up a new company called Bottlenose, using the same technology in a more focused application scenario, moving from 2C services to 2B services.

Bottlenose, which has been around for eight years, is still very successful. Relatively speaking, the application of 2B does not need so much data and does not have to solve the problem of system scalability, which highlights the core advantages of the system, that is, semantic analysis and understanding ability.

Examples of failures like Twine are not uncommon. When using an overly advanced architecture, you often face risks that are hard to anticipate at first, even not just niche products such as RDF databases, but also more popular products.

For example, some people often ask me, "do you have to use a graph database when you do the application of knowledge graph?" I usually say no.

If you are familiar with the graph database, for example, you are very familiar with the entire operation and maintenance of Neo4j, you know what to do if its JAVA virtual machine goes wrong; you know what to do when it does not have enough memory; you know how to slice data and how to copy it from master to slave. When all these operation and maintenance problems are familiar, you can try this application.

Don't be in such a hurry when using the application. If you are just an online application, you can put it aside for a while. First figure out this part of the offline operation and maintenance work, and then go online. You can also try using a small data set first. In short, don't take too big a step.

NO.5 cannot manage user expectations

The fifth method cannot manage user expectations.

This is a particularly common cause of project failure, not even because it is technically impossible, but because users expect it to be larger.

Let me first talk about something that is technically impossible, for example, there is a bank, they have launched the so-called robot lobby manager, you can talk to a robot to do business. Obviously, if this thing can really be done, it should be a very surprising thing, which is far beyond the current technological boundaries.

Recently, there is a more famous scam, which is the robot Sophia. Saudi Arabia also gave it the status of its first citizen, which is a very typical fraud.

This type of robot is unlikely to appear.

This situation will also be encountered in other applications, especially the conversation robot is the most likely to arouse users' desire for Turing testing. When a user discovers that he is talking to a robot, he will try to flirt with the robot. For example, many people will flirt with siri, so siri has accumulated a lot of jokes and is ready to deal with flirting.

If you provide a search engine, then everyone's expectations are relatively low. But if you provide the same content in the form of a question and answer engine, expectations will be much higher.

We first provided an end-level product, and the user's evaluation was not particularly good. Later, we adjusted the positioning and adjusted it to use the search interface to provide services, and the intelligence of the top layer of the system did not change much. But users' expectations and comments immediately improved, because user expectations were reduced. This kind of semantic search engine is actually better than other search engines.

In fact, the same is true of dialogue robots, if you give users expectations of robots that can talk to him on an equal footing, it is usually very difficult to achieve. Users usually find it silly after playing, and then stop playing, so people notice that Google Robot is very different from Apple's siri robot positioning. Google Robot does not only do conversations, it can help you do something in advance, and even take the initiative to help you do some automated things, in fact, this is a very smart choice.

At present, the robot that can interact with people for a long time is actually more secretarial, or it is a machine that helps you automate your tasks. If you are based on dialogue, it is difficult to meet user expectations, but if you are based on automation, it is easier to meet user expectations. The same technology, you use different ways to serve users, users expect different, users feel completely different. Therefore, it is necessary to make the user aware of the maturity of the product as much as possible, and the product can only be successful based on his expectations, and he is willing to pay.

NO.6 does not understand cognitive complexity

The sixth point is the inability to understand cognitive complexity.

I mentioned this at the beginning. This example is Semantic Wiki. I have written a lot of such systems. What is Semantic Wiki? Everyone must have used Wikipedia or Baidu encyclopedia, this is just a typical Wikipedia system, there are a lot of people to write a page. Semantic Wiki is also based on collaboration and is also a Wiki, but on this Wiki page, you can type some tags and add some comments.

What problem can it solve? For example, it can solve the one-time problem of data between pages, that is, the data on one page can be streamed to another page. For example, on Wikipedia, you can see the GDP of many countries, that is, the gross national product. On the Chinese page, there will be Chinese GDP, on the GDP list of Asian countries, there will also be Chinese GDP, and then on the GDP list of world countries, there will also be Chinese GDP. So is it possible to have a mechanism, such as writing down the GDP of China on one page? as long as this number changes, the numbers on all other pages will change synchronously, which can be done with Semantic Wiki technology. Of course, Semantic wiki can also do a lot of cool other things, very powerful.

I began to write Semantic Wiki system in 2004. I wrote three Semantic Wiki systems before and after. Later, I joined an open source community called Semantic MediaWiki. Based on such a system, I made a good knowledge management system.

In 2010, we tried to promote this system, and at that time, we did an experiment, which was also entrusted to us by a national institution in the United States, to test whether some events could be recorded well by using this collaborative knowledge management system. Good enough that the machine can automatically process it later.

In the comparative experiment at that time, a group of RPI computer science undergraduates were asked to watch the TV series and describe the plot after watching it. Some people describe it in natural language, others use Semantic Wiki to describe it in a more structured way. Then ask the students to read the descriptions of the first two groups of students, and finally ask them to do the exercises to see which group can restore the plot of the TV series more accurately. The final result is that it is easier to describe in natural language, that is, it is more accurate and faster.

Then we take a closer look at the structured descriptions written by those students and find that they are full of mistakes. For example, Zhang San hugged Li Si. For the so-called people who have knowledge engineering training, it is obvious that hugging should be a relationship. Zhang San and Li Si should be two people, one is the subject and the other is the object, then it should be the subject, predicate and object. Zhang San hugging Li Si is a very clear knowledge modeling. But quite a lot of students, they got such a very simple model wrong, they have no way to understand what the concept is? What is a relationship? What is an attribute? They don't even know what subject and object are? Then we found that when we first imagined this thing, we ignored the vast majority of people who did not have the training of structured thinking in their educational career, such as high school education, which was a cognitive complexity that could not be realized beforehand.

Since we have all been trained for more than ten years, we completely regard these things as natural things. Later, the same thing happened in OWL WORKING GROUP. Some people said that this thing was too complicated, and one of them protested that it was not complicated. When this thing ran on a computer, its algorithmic complexity was only polynomial complexity. Then after hearing this sentence, I suddenly realized that one thing was in the minds of these logicians. The complexity they refer to refers to the complexity of a language to the machine, so we usually call it computational complexity.

But in fact, the complexity that ordinary people understand is not like this. For example, what you can say in half a page is a simple thing. If I can see 20 pages before I can understand it, then this thing is a complex thing. So a technology, can you make programmers use it, can you let users use it? the core thing is, can you make them feel that this thing is easy to read, understand, and understand as soon as you open it? there is no need to explain. This is simple.

In the design of many algorithms, documents and applications, whether it can be used well in the end, the key is to make people feel that it is simple and easy to use, which is a very important factor. Stanford Parser, one of the important reasons why it is so widely used in the NLP field, is that it is well documented, each class has documentation, and provides enough cases.

So good documentation can greatly reduce the cognitive complexity of a product, even if your product itself is complex, and if you write the document well, it is enough to help promote the product, so try your best to make people who have access to your product. People who engage in language, technology, and algorithms all feel that this thing is simple and is a key to ensuring the success of your product.

Lack of professionalism in NO.7

Seventh, it is easy to understand that there is a lack of professionalism.

I often encounter people who say that so-and-so now wants to do a question and answer system, hoping to put in three or five people, probably without a doctor in most cases, or an engineer in most cases, trying to do it very quickly. Within two or three months, or even within three to five months, it is also a fantasy to do such a thing. Of course I won't just say it.

Artificial intelligence products do have their own expertise. Many organizations try to do such a thing by themselves, spending 10 million, 20 million, 30 million dollars unjustly, but can't do it. Indeed, it is very difficult to do such a thing without a professional person.

I have also experienced a lot of such things, and I have also experienced such problems in a semantic understanding system that I have done. I think to be able to complete such a system actually requires the synthesis of many different algorithms, which cannot be solved by one algorithm. For example, from a positive example, there are dozens of different algorithms in the IBM Watson system, including machine learning algorithms, natural language processing algorithms and knowledge graph algorithms. You have to put all these algorithms together just right, and the scale is a particularly important ability. What kind of things you should use, what kind of things you should not use.

For example, in the rule system, anyone can write 10 regular expressions, which is no problem. But if you can write 100 regular expressions, you must be a very good engineer, and your software engineering skills are excellent. If you can manage 1000 regular expressions, you must be a professional with professional knowledge management training. If you can really manage 10000 regular expressions, you must have a lot of experience in rule management.

Of course, when I said 1000 or 10000, I didn't mean that you copy paste 10000 times and change a few of the words, but that doesn't count. There are a lot of things about artificial intelligence, and that's where the difficulty lies. You go online to get an open source package or something, you can do 80% of it, it's easy to do it. But the difficulty lies in the last 20%, which may require 98% or 99% accuracy to meet the needs of users, but if you are not professional enough, these last points are very difficult.

For example, if you want to go to the moon, what you need is not a ladder, but a rocket. You move a ladder, and in the end you have to climb the tree, and you can't go up any more. What you need is to stop and build rockets. Building rockets is professional. If you are not professional enough, you will always stay at the 80% level and will never rise again.

Let's go back to the semantic understanding project we just talked about. At that time, we encountered a lot of difficulties, to be able to integrate rule methods, integrated statistical methods, integrated natural language processing methods. At that time, there were many laboratories around the world to do this thing together, but the lack of such a role, can handle all the standards very well.

In fact, IBM to make the Watson system, but also experienced a lot of internal changes, including changes in project managers, including a variety of technology selection changes, to be able to do this, this kind of talent is very scarce. In China, there are very few people who can really understand the architecture of a semantic system from beginning to end, maybe 10, maybe 20, and the number is really small. I believe the same situation is faced in other areas of artificial intelligence.

Professionalism is not limited to programs or technology. Product managers of artificial intelligence, operation of artificial intelligence projects, and the entire knowledge system and data management all need very professional people to do. Now these talents are very scarce.

Lack of engineering capacity of NO.8

The eighth method is lack of engineering capacity.

My doctoral thesis is a distributed inference engine, but because of the lack of programming ability, I was not able to implement it until I graduated. When it came to 2012 and 2013, when graph computing, including those based on message exchange, was done, it was easier for me to build a distributed inference engine.

But this is a big lesson for me.

After that, I am more concerned that if I do one thing, I will be able to make up my engineering ability first. This engineering capability includes software engineering capabilities, how to write code, how to manage code, how to do system integration, as well as regression testing, how to version control code, and so on. Later, when I interviewed people, I paid more attention to these things.

Whether an artificial intelligence technology can be done well, the core is often not only the algorithm, but the underlying architecture, as well as the system. For example, the paper is actually a very good distributed reasoning algorithm, but because of the lack of this architecture, I have no way to implement this thing. Later, such as in-depth learning is also the same. Recently, I saw that Chen Tianqi and their laboratory put the algorithm, architecture, and operating system into one laboratory to operate, and I felt that this was a very good thing. At present, the gap between algorithm and architecture is too big.

Engineering is the core key to solve artificial intelligence. If the code ability is not good, the architecture ability is not good, and the engineering ability is not good, in this case, we should not talk about algorithms at all. Priority should be given to making up the engineering capacity, and then talking about the algorithm.

The NO.9 lineup is too luxurious.

Ninth, the lineup is too luxurious.

It's hard to say what the specific project is. It's too sensitive.

But I'm just going to tell you logically. Because if a project is too luxurious, the core problem is sunk cost.

We also often see some start-ups, whether business or technical, particularly good people form a company, and eventually fail. Why? Because better people want to do big things. It's hard to do a big thing right at once. Usually big things grow up from small things. If we can't let the luxurious squad start from the small things, usually such a thing will fail.

The logic is very simple, so I won't say any more.

It is not the right time for NO.10 to have bad luck.

On the tenth point, I can leave all the other factors here, but not the right time and bad luck.

In fact, everything else can be attributed to bad luck.

For example, we now look at deep learning, such as attention, convolution, LSTM, associative memory and so on, all of these concepts were already available when I was a graduate student in the 1990s, but they could not be done at that time. At that time, even with these algorithms, there was no such computing power, even with such computing power, there was no such data.

In 2000, after I graduated with a master's degree, I was working on a hierarchical multi-layer neural network. We call it hierarchical neural network, which is very close to the idea of deep learning later. With this in mind, I went to see my doctoral mentor. He said that I wanted to continue to move forward in this direction, but he said that now the whole neural network could not get any investment, and you couldn't go any further, so I gave up this direction and was ready to be a semantic web. Ten years later, this method finally found an opportunity, and later became something of deep learning.

Many times, the time is not right, even if you have this algorithm, you can't do it. The neural network of the 1990s took almost a decade to recover.

The knowledge graph is the same, and it has been waiting for more than ten years, and it has only been applied on a large scale in recent years.

Summary

Let's take the opposite and make a summary:

Last but not least, talk about timing and luck.

Very often, we really don't know if this can be done, and we really don't know what kind of historical stage we are in. It is difficult to predict what the future will be, but at least we can better understand the future if we learn more about the development of algorithms, including the history of artificial intelligence, including the history of related technologies.

So I also recommend Mr. Nick's "A brief History of artificial Intelligence". I saw it twice and it was very rewarding. After looking at this thing, we can understand more about what is timing and what is luck.

Sometimes I often read some classic articles, the books of ten or 20 years ago, I read it is quite enlightening. For example, this year I re-read Tim Berners-Lee 's book Weaving the World wide Web, and after reading it again, I became confident.

Knowledge graph, a system that interconnects the memory of the world, is likely to be realized by 2030, which is still a long way off, but according to the law of history, it should be realized by 2030.

On the one hand, lower our current expectations, on the other hand, it also gives us greater encouragement to move forward.

Scene transition theory

Just mentioned again and again, to control users' expectations, to control their own expectations. To do a project, it should be done step by step from small to large. Finally, I abstracted everything to a higher level, and I summed it up as a theory, called scene transition theory.

The core of this theory is that an artificial intelligence company needs multiple product market matches, that is, Product-Market Fit. If a product is provided, the market just needs it, and the market is very large, that is to say, there is a product market match.

Classic Internet entrepreneurship, usually do a product market match, can be successful. But artificial intelligence often has to be done several times, and Internet companies are very different from artificial intelligence companies.

One is called the chicken farm model, and the other is called the child raising model.

Internet company is a chicken farm model, it is a large-scale complex system Complex system. The key to it is scalability. I raised a chicken, I found that this chicken is good, I raise 10,000 chickens, this is the chicken farm model. The core is how to raise 10,000 chickens, which is called scalability.

Artificial intelligence applications are another type of complex system called Complicated system, which has a lot of components, usually hundreds of strange components. Its core is not raising ten thousand chickens, but more like raising a child, having a child, changing his diaper from childhood, feeding him, teaching him to walk, teaching him to talk, teasing him, raising him in primary school, high school, and college all the way. The main tasks facing each stage are different. How can you let this child grow up? we call it progressibility. this is the core factor of AI.

It is actually not easy to raise an AI company. Just like raising a child, it is often very hard to build a team and build a foundation for the first five years. The idea of corporate survival is how to make money gradually in the process of evolution, rather than trying to find the combination of market products in one step. Not only to make money in the stage of artificial intelligence, but also to be able to make money in the stage of artificial intelligence.

How can you make money without a complete system? Only some components in the system can be taken out and partially commercialized. Just like a caterpillar to a butterfly, a caterpillar has to shed its skin several times before it can become a butterfly. In the caterpillar stage, it eats tree leaves, and in the butterfly stage, it eats nectar, so its business model is completely different in two different stages. Artificial intelligence companies also have to shed their skin several times. In the early days, because the products are not perfect, so artificial intelligence companies are early outsourcing companies, this is normal, it should be accepted, this is a necessary stage of development.

To sum up everything we have said today, artificial intelligence is a new thing, it is a very complex thing. It is difficult to use traditional old experience to set up the development of such a thing. It must go through a long period of evolution before it can reach a mature state. And this evolutionary force is the most critical factor that we want to make a successful business attempt. How to ensure that in the scene transition again and again, the team does not fall apart, this ability is the biggest key to determine the success of a business.

I think many reasons are the same not only for business, but also for doing research at school or in large multinational companies. Is how to do it step by step, from childhood to earth, thank you!

-end-

Https://zhuanlan.zhihu.com/p/41061140

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.