(paper comment) Concrete Problems in AI Safety


I can only think of this paper as great. It explains the current unsolved problems of AI, and by looking at it, I thought about how God made humans. And people usually think that robots have no emotions, but I thought that it can be made! Looking at the paper, it overlaps with the memories that trained my dog’s bowel training, and I thought that it may be related to not only the education of artificial life(or intelligence) but also the interaction (or education) of living and human beings in the natural ecosystem.

This is the first paper that leads me have various ideas and imagination when I read it. It’s so fun and I really think humanity needs to control this topic. Likewise a man is not uncontrollable if it is not educated in his childhood, I thought that an artificial intelligence could be similarly if it is not educated.

In fact, I don’t know if humans can control this finely. In that sense, I feel fears in this situation. I thought that the situation in the scene of Matrix can be one of our possible futures.

This paper is really fun. There are a lot of references to related studies, which can help you keep track of them.


이 논문은 정말 대단하다고 밖에 생각할 수 없다. 인공지능의 현재 해결되지 않은 문제들을 설명해 주고 있는데, 그것을 보면서 하나님이 인간을 어떻게 만드셨을까를 생각해 보게 되었고, 보통은 로봇이 감정이 없다고 생각하는데 마치 이 논문을 보면서 감정이라는 것이 만들어질 수도 있겠구나! 라고 생각했다. 논문을 보면서 우리집의 강아지의 배변훈련을 시켰던 기억들과 오버랩되면서 이게 인공 생명체에 대한 교육 뿐만 아니라 현재 자연 생태계에 있는 생명체와 인간과의 상호작용(혹은 교육이라고도 볼 수 있는)과도 연관이 있을 수 있겠다고 생각했다.

논문을 보면서 이렇게 오만가지 잡생각과 상상을 하면서 본 논문은 처음이다. 그만큼 재미 있고 이 주제를 정말 인류가 제어를 해야 할 필요가 있겠다는 생각이 들었다. 왜냐면 사람도 어렸을때 제대로 교육을 받지 못하게 되면 제어가 불가능하고 말썽을 부리는 사람이 되듯이 인공 생명체도 그리 될 수도 있겠다는 생각이 들었다.

사실 인류가 인공 지능을 그만큼 이것을 세세하게 제어를 할 수 있을지에 대해서는 잘 모르겠다. 그런 측면에서는 두려움도 생기게 되었다. 매트릭스 영화에서 나온 장면의 상황은 우리의 가능한 미래들 중에 하나일 수도 있겠다는 생각이 들었다.

이 논문 진짜 재미있다. 관련 연구를 레퍼런스 한것도 엄청 많이 해 놓아서 연구들을 추적하는데도 도움이 많이 된다.

Fault injection test vs safety analysis


What do you think the purpose of the fault injection test is? Why do safety analysis?

Why do I talk these two together? Of course they are related.

In conclusion, the list or type of faults required in the fault injection test and the location and timing of the fault injection should be based on the results obtained during the safety analysis.

Suppose we have identified a list of faults that affect the safety performed in the safety analysis, and we have identified how to handle such faults as safety requirements (we call this the safety mechanism).

How can you verify them? Naturally, you will have to create a condition for the safety requirement to become active, which is the situation where the fault is injected.

So the two are related.


fault injection test의 목적이 무엇이라고 생각하는가? safety analysis는 왜 하는가? 왜 나는 이 둘을 엮을라고 하는 것인가? 당연히 관련성이 있기 때문에 그런 것이다

결론을 말하면 fault injection test에서 필요한 fault의 list나 type 및 fault를 injection하는 위치나 시점 등은 safety analysis에서 수행하는 동안 얻은 결과를 바탕으로 해야 한다.

safety analysis에서 수행한 안전에 영향을 끼치는 fault list를 식별을 했고, 그런 fault들을 처리하는 방법을 안전 요구사항으로 식별했다고 치자(우리는 이것을 안전 매커니즘이라고 부른다.)

여기서 그 안전 매커니즘에 대한 검증을 어떻게 할 것인가? 당연히 safety requirement가 활성화되기 위한 조건을 만들어줘야 할 것이다, 그것이 바로 fault가 inject된 상황이 된다.

그래서 둘은 이렇게 연관이 있다.

System vs System of systems; what are different?


When I was thinking about V2I or V2X, the motivation that led me to the concept of system of systems was just vaguely the system of systems (SoS),
Something like that term came up tremendously and made a huge system.
However, looking at this paper, my prejudice was completely shattered.

In fact it was a little shocking. This paper appeared a long time ago. Nevertheless, I couldn’t grasp the concept yet, so I still had a lot to learn.

First, I created a table to compare the system and SoS.

System

SoS

characteristics

Each component is not considered to be a system individually.

Each of the components can be considered as a system individually, and each individual system can be managed independently from the operation.

controllability

controllable. Centralized

 

It is not fully controllable. Excessive attempts to control fail due to lack of authority.

plan

planned

evolutionary. There is no guarantee that system components will continue to cooperate. The system may initially flow in unintended directions.

operation and management independence

Components within the system scope cannot operate independently.

Components within the system scope can operate independently.

Key point in the architecture

components in the system

interfaces between systems

It was important to know whether the target was an ‘a system’ or a ‘a SoS (system of systems)’. If you think that the system is ‘a system’ and develop it, but the property of the system is ‘a SoS’
It is not possible to develop it sufficiently deliberately, so it can evolve in unexpected ways and cause the project to run out of control.
If the designer thought the target would be fully controllable, and development would have to be done in a collaborative manner, that would make the project very difficult.

The opposite is also true. If the individual components are independent and each moves cooperatively, but each has its own operating rights within the individual category, then it is not suitable for a centrally controlled model.

Also, if the related technology has not been developed yet, and if only the interface is made and the design is not designed in a way that allows any way, the related technology can be developed together with the details and the details can not be used when new technologies are released.

In the end, it is necessary to understand the property of the system to be developed in depth. If it is a system, it is planned and centrally controlled. If it is a system of systems, it should be developed as an evolutionary and cooperative model.

I think the distinction between the two must be understood to make a big system.

Back in v2x and v2I, mentioned in the introduction, do you think they should be concepts? Although we still need additional studies for the concrete concept, I think it would be better to see it as a cooperative model (hence a SoS).

Related papers: Architecting Principles for Systems-of-Systems (1998)


 

system of systems라는 개념에 관심을 두게 된 동기는 V2I나 V2X에 대해 생각해 봤을때, 그냥 막연하게 SoS(system of systems)라고 생각했었고,
뭔가 그 용어가 굉장히 거창하게 다가와서 거대한 시스템을 만드는 것 같은 느낌을 받았다.
하지만, 이 논문을 보고 내가 가진 편견은 완전히 산산조각이 났다.

사실 좀 충격이었다. 이 논문이 나온것은 굉장히 오래전에 나왔다. 그런데도 아직 개념을 못잡고 있는 것을 보니 아직도 배울게 많다는 생각이 들었다.

일단 시스템과 SoS를 비교할 수 있는 표를 만들어보았다.

System

SoS

특징

구성요소 각각은 개별적으로 시스템으로 간주되지 않는다.

구성요소 각각은 개별적으로 시스템으로 간주될 수 있고, 각 개별 시스템은 운영 독립성과 독립적 관리의 특성을 갖는다.

제어가능성

통제 가능하다.

fully 통제 가능하지 않다. 과도한 통제 시도는 권한 부족으로 실패한다.

계획성

계획적이다.

진화적이다. 시스템 구성요소가 지속적 협력한다는 것을 보장하지 못함. 시스템이 초기에 의도하지 않은 방향으로도 흘러갈 수 있다.

운영 및 관리독립성

시스템 범위내의 구성요소들은 독립적으로 작동할 수 없다.

시스템 범위내의 시스템들은 독립적으로 작동할 수 있다.

관리의 중앙집중화

중앙집권적

보이지 않는 손에 의한 관리

아키텍처의 Key point

시스템 내의 컴포넌트

시스템들간의 인터페이스

 

그 target이 ‘a system’인지 아니면 ‘a SoS(system of systems)’인지를 파악하는 것이 중요함을 알았다. 만약 해당 시스템을 ‘a system’이라고 생각하고 개발을 했으나, 실제 해당 시스템의 속성이 ‘a SoS’라면
충분히 계획적으로 개발하는 것이 불가능하고, 그렇기에 예상치 못한 방향으로 진화가 되어 통제가 불가능하게 프로젝트가 폭주할 수가 있게 되는 것이다.
만약 설계자가 그 target이 fully controllable할 것으로 생각했는데, 그렇지 않고 협력적인 방식으로 개발이 이루어져야 한다면 그것도 프로젝트가 매우 어려워지게 되는 것이다.

그 반대도 마찬가지가 된다. 개별 컴포넌트가 독립적이고 각각이 상호 협력적으로 움직이되 개별 범주내에서는 독자적인 운영권한이 있게 된다면 중앙통제적인 모델에는 적합하지 않게 된다.

또한 아직 관련 기술이 개발되지 않아서 인터페이스만 만들어놓고 어떤 방식이든 허용하는 방향으로 설계를 하지 않고 관련 기술도 함께 개발하고 디테일 한 것 까지 세부적으로 개발을 하게 된다면 새로운 기술이 나올때 그것을 활용할 수 없게 된다.

결국 개발하고자 하는 시스템의 속성을 깊이 있게 파악을 해야 하며, 그것이 a system이면 계획적이면서 중앙통제적으로 개발을 하는 것이고, a system of systems이면 진화적이면서 상호협력적인 모델로 개발을 해야 하는 것이다.

그 둘의 구별은 큰 시스템을 만들려면 반드시 이해하고 있어야 한다고 생각한다.

서론에 언급했었던 v2x와 v2I로 돌아와서, 그렇다면 그들은 그럼 컨셉이 되어야 한다고 생각하는가? 비록 아직 구체적인 컨셉에 대해서는 추가적인 스터디가 필요할 것으로 생각하지만, 현재로서는 상호협력적 모델(그러므로 a SoS)로 보는게 더 낫지 않을까 생각한다.

관련 논문: Architecting Principles for Systems-of-Systems (1998)

 

system of systems라는 개념에 관심을 두게 된 배경은 V2I나 V2X가 되면 그냥 막연하게 system of systems라고 생각했었고, 뭔가 그 용어가 굉장히 거창하게 다가와서 거대한 시스템을 만드는 것 같은 느낌을 받았다. 하지만, 이 논문을 보고 내가 가진 편견은 완전히 산산조각이 났다.

사실 좀 충격이었다. 이 논문이 나온것은 굉장히 오래전에 나왔다. 그런데도 아직 개념을 못잡고 있는 것을 보니 아직도 배울게 많다는 생각이 들었다.

일단 시스템과 SoS를 비교할 수 있는 표를 만들어보았다.

설계자가 개발하고자 하는 범위에서 그 시스템이 a system인지 아니면 system of systems인지를 파악하는 것이 중요함을 알았다. 만약 해당 시스템을 a system이라고 생각하고 개발을 했으나, 실제 해당 시스템의 속성이 SoS라면 충분히 계획적으로 개발하는 것이 불가능하고, 그렇기에 예상치 못한 방향으로 진화가 되어 통제가 불가능하게 프로젝트가 폭주할 수가 있게 되는 것이다. fully controllable할 것으로 생각했는데, 그렇지 않고 협력적인 방식으로 개발이 이루어져야 한다면 그것도 프로젝트가 매우 어려워지게 되는 것이다.

그 반대도 마찬가지가 된다. 개별 컴포넌트가 독립적이고 각각이 상호 협력적으로 움직이되 개별 범주내에서는 독자적인 운영권한이 있게 된다면 중앙통제적인 모델에는 적합하지 않게 된다, 또한 아직 관련 기술이 개발되지 않아서 인터페이스만 만들어놓고 어떤 방식이든 허용하는 방향으로 설계를 하지 않고 관련 기술도 함께 개발하고 디테일 한 것 까지 세부적으로 개발을 하게 된다면 새로운 기술이 나올때 그것을 활용할 수 없게 된다.

결국 개발하고자 하는 시스템의 속성을 깊이 있게 파악을 해야 하며, 그것이 a system이면 계획적이면서 중앙통제적으로 개발을 하는 것이고, a system of systems이면 진화적이면서 상호협력적인 모델로 개발을 해야 하는 것이다.

그 둘의 구별은 큰 시스템을 만들려면 반드시 이해하고 있어야 한다고 생각한다.

서론에 언급했었던 v2x와 v2I는 그럼 무엇으로 보아야 할까? 그러고 보니 내가 v2I나 v2x에 대한 컨셉이 없다는 것을 알았다. 상호협력적 모델로 보는게 더 낫지 않을까 생각한다.

관련 논문: Architecting Principles for Systems-of-Systems (1998)