Category Archives: machine learning

SW Development Process using Artificial neural networks


This posting refers a paper whose title is “A software development process model for artificial neural networks in critical applications(1999)”.

It is very interesting paper and it will help readers can understand what SW development processes using AI are even though they don’t have deep knowledge about AI.

It is an old paper, and I’d like to search a new one. but it can be a good starting point from it.

Motivation for reading this paper is that I don’t have any knowledge about AI, but it seems to be a trend to use AI to develop SW. so I’d like to understand what is a SW process using AI. This paper satisfies my motivation fully.

For Korean readers, I translated into Korean language and it will help them to read faster.

For non-Korean readers, you can access the paper directly.

 

Abstract

중요한 응용 분야에서 인공 신경망 (ANN)을 사용하는 것은 ANN 구성의 실험적 특성과 ANN에 자주 부착되는블랙 박스레이블로 인해 까다로울 수 있습니다. 소프트웨어 유효성 검사 및 승인을 용이하게하는 알고리즘 소프트웨어 개발을 위해 널리 수용되는 프로세스 모델이 있습니다.

여기에 제시된 소프트웨어 개발 프로세스 모델은 특히 중요한 응용에서 인공 신경망을 목표로합니다. 이 모델은 다루기 어렵지 않으며 중요한 측면없이 프로젝트에 쉽게 사용할 수 있습니다. 이는 ANN을 사용하고 CMM (Capability Maturity Model) 또는 ISO 소프트웨어 개발 등급을 유지하거나 달성해야하는 조직에게 특히 중요합니다.

또한,이 모델은 약간의 수정으로 신경망 개발을 직접 목표로하지만, 다른 수치 적 접근 또는 지식 기반 시스템과 같은 기존 데이터로부터 지식이 추출되는 모든 기술에 적용 할 수 있습니다.

Introduction

알고리즘 소프트웨어는 프로그램이 무엇을해야하는지 정확하게 알려주는 정량화 가능한 단계 세트를 통해 개발되는 반면, 인공 신경망은 네트워크가 알아야 할 정보를 훈련 프로그램에 제시함으로써 구성됩니다.

Neural Network Development

중요한 시스템이든 아니든 모든 시스템은 엄격한 개발 표준에 따라야 한다고 주장할 수 있습니다. 이것이 ANN에서 드문 이유는 두 가지입니다.

첫째, 신경망 구축 및 훈련의 부정확 한 특성으로 인해, 개발은 [2]에 제시된 사례 연구에서 볼 수 있듯이명백하게 경험적이거나 실험적인 특성“[1]을 갖는다.

둘째, 신경망의 지능은 숫자 시냅스 가중치, 연결, 전달 함수 및 기타 네트워크 정의 매개 변수 모음에 포함되어 있습니다. 일반적으로, 이러한 수량을 검사하면 특정 결과가 생성되는 이유에 대한 명확한 정보가 거의 없습니다.

이 두 가지 요소의 조합으로 인해 신경망에 대한 공식 사양이 무시되거나 존재하지 않는 경우가 종종 있습니다. 신경망 개발자는 종종 데이터로 할 수있는만큼의 접근 방식을 취하며, 추가적인 노력으로 무증상으로 개선이 이루어지면 시스템은 충분하다고 간주됩니다. 이해하기 어려운 시스템이 중요한 응용 프로그램에 포함되어있는 경우에는 이 방법으로는 충분하지 않습니다.

신경망과 알고리즘 프로그램의 주요 차이점에 관계없이 ANN에 공식적인 개발 방법론과 검증 기술을 도출할 수 없는 근본적인 이유는 없습니다.

실제로 신경망을 호스트 애플리케이션에 포함시키기 위해서는 ANN 호출 모듈의 단순한 특성으로 인해 이를 둘러싼 복잡한 코드보다 훨씬 쉽게 인증할 수 있다고 주장할 수 있다 [3]. 일반적인 “Waterfall”[4] 또는 “Spiral”[5] 소프트웨어 수명주기 모델 모두 인공 신경망의 개발에 잘 적용되지 않습니다.

사전에 정식 성능 및 인터페이스 요구 사항을 개발하는 것은 일반적으로 불가능합니다. 대부분의 교육 데이터에 포함 된 일관성 수준에 대한 확실한 단서가 없기 때문입니다.

데이터 전처리에는 일반적으로 호출 기능에서 ANN으로 어떤 데이터를 전달해야 하는지 명확하게하기 전에 많은 시행 착오 반복이 필요합니다.

오히려 ANN 개발자들이 일반적으로 그들의 노력에 포함시키는 6 가지 단계는 다음과 같습니다 [6] :

1) 요구 사항 및 목표의 수립

2) 훈련 및 시험 데이터 세트의 선택;

3) 신경망 아키텍처의 선택;

4) 네트워크 훈련;

5) 네트워크 테스트;

6) 고객의 수락 및 사용.

항목 (1)은 특히 매우 미묘한 세부 사항을 포함합니다. 신경망 훈련에 존재하는 불확실성을 감안할 때, 선행 목표는 별도로 기술되어야한다. 또한 ANN 교육은 일반적으로 매우 반복적이며 (5)에서 (2) 로의 루프백이 매우 일반적입니다.

그러므로 여기서 목표는이 오랜 테스트 (연구 및 개발 중심) 방법론을 제어, 추적 및 분석 할 수있는 공식적인 프로세스로 만드는 것입니다.

이것이 달성 될 수 있다면, 신경망 개발은 주류 소프트웨어와 동일한 수준의 책임으로 이루어질 수 있으며, 신경망 프로젝트의보다 쉽게 ​​공식적인 인증을받을 수있는 문을 열어줍니다.

Neural Network Risk Management

신경망 개발 과정의 일부를 공식화하기위한 일부 노력이 진행 중입니다. 미국 식품의 약국 (FDA) 의료 기기에 내장 ANN 대해 취해야 단계에 관한 광범위한 지침을 발표했습니다. 문서는 또한관심 수준 기반한 내장형 의료 신경 네트워크 프로젝트에 대한 다양한 수준의 형식론을 지원합니다. 영국에서는 안전에 중요한 시스템에서 ANN 인증하기위한 공식 표준에 대한보다 자세한 작업이 진행되고 있습니다. ANN 파생 프로세스가 복제 가능하고 모호하지 않도록하기위한 표준 초안이 검토를 위해 공개되었으며 [8] 여기에 요약되어 있습니다.

Designing the Network

  • 높은 수준의 목표를 문서화해야합니다.
  • 네트워크 아키텍처를 완전히 지정해야합니다.
  • ANN은 입력 매개 변수 공간에서 출력 충실도를 검증 할 수 있어야합니다.

Training the Network

  • 데이터 세트는 높은 수준의 목표와 일치해야합니다.
  • 개발자는 데이터 수집을 문서화해야합니다.
  • 사전 처리 및 사후 처리 활동을 문서화해야합니다.
  • 개발자는 입력 매개 변수 공간에 큰 간격이 없는지 확인하기 위해 데이터를 검사해야 합니다.
  • 개발자는 사용 가능한 교육 데이터와 관련하여 네트워크의 정확성을 자세히 설명해야 합니다.

Interfacing the Network

  • 개발자는 사전 처리 및 사후 처리 및 응용 프로그램 타이밍을 위해 시스템에 필요한 ANN 연결을 지정해야합니다.

Process Certification Requirements

  • 개발 팀 관리자는 신경망을 이해해야합니다.
  • 팀 구성원은 각각 ANN 개발 프로세스에서 자신의 역할을 이해해야 합니다.
  • ANN 리콜 루틴은 승인 된 공식 방법을 사용하여 개발해야 합니다.
  • 작업 분해는 ANN 개발 프로세스를 반영해야 합니다.
  • ANN 교육 데이터베이스를 조립할 때 QA 방법을 사용해야 합니다

Testing the Network

  • V & V 팀은 개발 팀과 독립적입니다.
  • V & V 팀은 데이터베이스에 포함 된 기본 원칙을 일반화 할 수있는 ANN의 능력을 보장해야합니다.
  • V & V 팀은 호스트 애플리케이션에서 ANN 작동을 확인해야합니다.

Risk Analysis

  • 개발자는 ANN이 표준 위험 평가 방법론과 일치하는지 확인해야합니다.
  • 개발자는 가능한 ANN 고장 모드를 설정해야 합니다.
  • 개발자는 네트워크를 통해 호출 루틴에서 입력 오류 전파를 조사해야 합니다.
  • 개발자는 네트워크에서 호출 루틴으로 오류 전파의 영향을 조사해야 합니다.
  • 위험 분석은 개발 및 V & V 팀이 독립적으로 수행해야 하며 인증 전에 보고서를 조정해야 합니다.

위에서 설명한 요구 사항은 신경망의 기술 개발 및 성능과 관련된 위험에 중점을 둡니다. 주류 위험 관리에는 비용, 일정 및 유지 관리를 포함한 다른 유형의 위험도 포함됩니다.

이러한 문제는 알고리즘 프로젝트보다 ANN 개발에 크게 관심이 없습니다.

특히, ANN 개발 프로젝트의 규모는 일반적으로코드 작성프로젝트보다 작으며 데이터베이스 분석 및 데이터 준비 / 사전 처리와 같은 보조 작업을 통해 많은 노력을 기울입니다.

대부분의 ANN 개발 프로젝트는 몇 주에서 몇 달에 이르기까지 다양합니다.

신경망이 더 큰 응용 프로그램에 포함 된 프로젝트의 경우 호스트 응용 프로그램은 일반적으로 개발 노력의 큰 부분을 수반합니다. 신경망의 경우 유지 관리 위험이 최소화됩니다.

The Nested Loop Model of the Neural Network Development Process

이전 섹션에서는 신경망 개발 커뮤니티에서 널리 사용되는 현재 관행과 ANN 개발의 위험 관리에 대한 문헌 지원 검토에 대해 설명했습니다. 이 섹션에서는 기존 개발 모델과 유사한 독창적 인 개념을 제시합니다.

그림 1은 새로운 프로세스 모델의 그래픽 표현입니다. 그것은 폭포 모델과 나선형 모델의 일부 측면을 지나치는 것 이상의 의미를 지닙니다. 프로세스 요소를 면밀히 검사하면 신경망 개발에 필요한 근본적인 차이점이 드러납니다. 이 프로세스의 가계도에는 기존 프로세스 모델 [9], 표준 ANN 개발 관행 [6], 초안 인증 표준 [8] 및 저자의 건강에 중요한 ANN 개발 경험 [10]이 포함됩니다.

Step 1: Network Requirements, Goals, and Constraints

프로세스 다이어그램의 번째 주요 블록은 사양 작업을 나타냅니다. 여기에는 확실한 네트워크 요구 사항 ( : 최종 출력), 목표 ( : 원하는 정확도) 제약 조건 (프로그래밍 언어, 메모리 제한, 최대 런타임 ) 문서화되어 있습니다. 작업은 ANN 개발자, 제품 관리자 호출 기능의 사양을 담당하는 개인이 공동으로 수행해야합니다. 활동의 결과는 네트워크 성능 사양입니다. 문서는 신경망 도메인을 약간 수정하여 축소된 소프트웨어 요구 사항 사양에 따라 패턴화 있습니다.

Step 2: Data Gathering and Pre-processing

이 프로세스의 다음 단계는 데이터 수집 및 전처리입니다. 데이터 수집에는 신경망 훈련에 사용될 모든 데이터를 조립하는 것이 포함됩니다. 데이터베이스, 스프레드 시트, 기타 컴퓨터 파일 또는 인쇄물에서 찾을 수 있습니다. 데이터 준비와 관련된 모든 활동을 기록해야 합니다.

여기에는 데이터 소스, 데이터의 원래 형식, 데이터를 일관되게 형식화하기 위해 수행된 수정 사항 및 사용 가능한 데이터의 가계도 또는 충실도에 대한 정보가 포함됩니다. 이 단계에서 수행되는 전처리는 사용중인 신경망 훈련 패키지와 일치하는 전자 형식으로 데이터를 수집하기 위한 것입니다 (데이터신경화“).

이 단계는 교육 데이터베이스에 대한 추적성을 제공하는 데이터 분석 문서를 생성합니다. 이 문서는 주로 모든 데이터 수집 및 전처리 작업에 대한 로그로 구성됩니다. 사용 가능한 형식으로 조립하는 데 사용된 모든 프로그램 또는 매크로와 함께 모든 데이터 (전자 또는 종이) 이 문서에 첨부되어야 합니다.

Step 3: Training and Testing Loops

프로세스 차트의 중심에는 신경망이 실제로 훈련된 요소가 포함됩니다. Training and Testing Loops 반복 프로세스를 나타냅니다.
중첩 루프는 거의 모든 소프트웨어 개발자에게 친숙해야 합니다. 애플리케이션은 가장 안쪽 루프인ANN 토폴로지의 변화 것입니다. 이는 패러다임 내부 아키텍처 매개 변수의 변경을 나타냅니다. 예를 들어 다층 퍼셉트론의 경우 여기에는 숨겨진 레이어 , 레이어 뉴런, 활성화 기능 선택, 바이어스 뉴런 연결 유사한 매개 변수의 변화가 포함됩니다.

 

Fig1.PNG

중간의“ANI 패러다임의 변화루프에는 보다 기본적인 네트워크 수정 사항이 포함되어 있습니다. 이 루프에서 개발자는 다층 퍼셉트론, 방사형 기본 함수 또는 다른 많은 ANN 패러다임을 실험할 수 있습니다. 가장 바깥 쪽 루프는“ANN 입력 뉴런의 선택 및 조합입니다. 여기에서 변경한 사항은 ANN이 모델링 할 기본 입력에 영향을 줍니다.

출력 공간을 지정하기 위해 사용 가능한 모든 입력이 필요한 것은 아닙니다. 다른 경우에는 동적 범위를 줄이거나 노이즈를 제거하거나 데이터를 시간 평균화하기 위해 입력을 사전 처리해야합니다. 또 다른 경우에, 입력 변수의 비선형 조합은 강력한 지표이며 신경망 훈련은 이러한 변수를 밝히지 않습니다. 이 유형의 변형은이 가장 바깥쪽 루프에서 수행됩니다.

루프의 중첩 순서는 약간의 네트워크 변경이 가장 안쪽 루프에 포함되고 중간 변경은 중간 루프에 있으며 기본 네트워크 입력 변경은 가장 느리게 변경되는 가장 바깥 쪽 루프에서 처리되도록 선택 되었습니다.

이것은 논리적으로 보이지만 일부 문제의 경우 가장 내부에 있는 두 개의 루프를 결합하거나 가장 바깥쪽에 있는 두 개의 루프를 바꾸거나 유사한 배열로 루프의 중첩을 수정할 수 있습니다.

또한 일부 최신 신경망 교육 패키지는 이 프로세스의 대부분을 자동화하며 일단 교육이 시작되면 사용자는 거의 제어할 수 없습니다. 이러한 경우 자동 네트워크 구성 결과가 면밀한 검사없이 수락되지 않도록 각별히 주의해야 합니다.

이 프로세스 단계에서 데이터베이스가 완전하고 일관성이 있는 경우 개발자에게 명확해야 합니다. 개발자는 이 단계에서 데이터베이스를 검사하여 입력 매개 변수 공간이 충분히 채워졌는지, 즉 데이터베이스에 큰 간격이 없는지 확인해야 합니다.

네트워크가 수렴하지 않으면 문제가 명시되지 않았으며 추가 입력 매개 변수를 조사해야 한다는 것도 분명해질 수 있습니다. 이 두 가지 상황 중 하나 (불완전 성 또는 불완전한 사양)가 발생하면 개발자는 추가 작업을 위해 데이터 수집 및 전처리 단계로 돌아가야 합니다.

네트워크 교육에 대한 모든 개발자 활동은 네트워크 교육 요약에 문서화 되어야 합니다. 이 문서에는 시도된 모든 순열의 전체 목록과 달성된 결과가 포함되어야 합니다.

훈련 단계에서 사용되는 일반적인 프로세스에 대한 간단한 논의와 함께 로그 시트 수집으로 충분합니다. 중간 교육 세션의 출력 및 네트워크 파일이 필요하지는 않지만 사용되는 모든 입력 데이터 파일은 전자적으로 (문서에 서면 설명으로) 첨부해야 합니다.

Step 4: Network Deployment

개발자가 신경망이 성능 요구 사항과 목표를 충족하고 ANN 개선이 수익 감소 시점에 도달한 것으로 만족한 후에는 일반적으로 네트워크를 호스트 응용 프로그램에 배포해야 합니다. 대부분의 상업용 신경망 훈련 도구에는 런타임 기능이 포함되어 있지만 대부분의 ANN은 결국 다른 프로그램에 내장된 모듈로 배포됩니다. 이 작업을 수행하는 일반적인 세 ​​가지 방법이 있습니다.

첫째, 많은 상용 도구에는 훈련된 네트워크 파일에 링크할 수 있는 런타임 라이브러리가 포함되어 있습니다. 이 경우 연결 절차에 대한 지침을 따르는 것 외에 개발자의 책임은 거의 없습니다. 두 번째 방법은 많은 상용 도구에서 제공하는 자동 코드 생성 기능입니다. 네트워크를 학습 한 후 호스트 응용 프로그램 내에서 컴파일 할 소스 코드를 다양한 컴퓨터 언어로 만들 수 있으며 C / C + Visual Basic이 가장 널리 사용됩니다. 다중 플랫폼 언어의 경우 프로젝트에 사용중인 특정 컴파일러에 대한 코드를 사용자 정의해야 합니다.

마지막으로 일부 상용 프로그램 (및 자체 개발한 대부분의 ANN 도구)에는 원시 네트워크 데이터를 텍스트 파일로 저장하는 것 이상의 기능이 없습니다. 이 경우 개발자는 ANN 데이터를 로드하고 네트워크를 실행하기 위해 코드를 작성하거나 다른 방식으로 획득해야 합니다.

이러한 유형의 작업을 정기적으로 수행하는 대부분의 조직은 약간의 수정만으로 모든 네트워크에 적용할 수 있는 기능 저장소를 구성합니다. 개발자는 배포 노력을 문서화하고 수동 또는 자동으로 생성된 모든 소스 코드를 네트워크 통합 문서에 기록해야 합니다.

개발자가 주요 배포 모듈을 만들어야 하는 경우 코드의 해당 부분을 호스트 응용 프로그램 개발 프로세스의 제어하에 두어야 합니다. 링크된 라이브러리, 자동 코드 생성 또는 이전에 승인된 사내 라이브러리를 사용하는 경우 개발자는 인터페이스의 소스 문서에 대한 참조를 제공해야합니다.

마지막으로, 입력 및 출력 매개 변수에 대한 필수 데이터 사전 및 사후 처리 요구 사항은 ANN이 야기 할 수있는 오류 조건의 분석과 함께 명시적으로 정의되어야 합니다.

Step 5: Independent Testing and Verification

개발자가 모든 제약 조건이 충족되고 모든 효율성이 문서화되었다고 확인되면 프로젝트는 검증을 위해 테스트 그룹으로 전달됩니다. 테스트 그룹의 첫 번째 작업은 주로 네트워크 성능 사양 및 데이터 분석 문서를 기반으로 네트워크 테스트 계획을 작성하는 것입니다. 테스트 계획에는 데이터 수집부터 개발 노력의 모든 단계에 대한 비판적 검토가 포함되어야합니다. 원본 데이터베이스는 무결성을 검사해야합니다.

승인된 절차에 대해서는 전처리 과정을 검토해야합니다. 훈련 데이터베이스는 통계적으로 검사하여 개발자가 전처리 활동에 의도하지 않은 편견을 유발하지 않았는지 확인해야합니다. Training and testing phase는 엄격하고 완전한 프로세스를 검사해야합니다. 참고 문헌 [11], [12] [13]은 신경망의 정확성을 평가하는 데 사용할 수있는 일련의 메트릭을 제시합니다. 코드 생성이 올바르게 수행되도록 배포 작업을 분석해야합니다.

이러한 단계 중 하나 이상이 부족한 것으로 밝혀지면 테스트 그룹은 프로그램을 데이터 수집 단계로 다시 되돌릴 수 있는 권한이 있습니다. 프로세스 다이어그램에는 데이터 수집으로 돌아가는 루프 만 표시되어 있지만 프로젝트는 교육 및 테스트 또는 배포 단계로 적절하게 재설정 될 수도 있습니다.

수행된 모든 테스트 요약 및 테스트 프로그램 또는 데이터베이스의 전자 사본을 포함한 테스트 그룹의 활동은 다음과 같아야합니다. 네트워크 테스트 보고서에 문서화되어 있습니다. 이 보고서에는 해당되는 경우 결함 해결 및 재시험에 대한 섹션이 포함되어야합니다.

Conclusion

이 논문은 중요한 어플리케이션에서 인공 신경망을 위한 소프트웨어 개발 프로세스 모델을 제시했다. 그러나 많은 신경망이 더 큰 개발 노력의 일부일 뿐이라고 위에서 언급했다. ANN은 확실히 소프트웨어 이므로 왜 모듈이 자체 개발 프로세스 모델이 필요한가?” 라는 분명한 질문이 있습니다. 호스트 응용 프로그램의 개발 모델을 ANN 모듈에 적용하는 것이 더 논리적으로 보입니다. 이 질문에 대한 답은 이중적입니다.

첫째, 신경망에 대해 실제로코드를 작성하지 않기 때문에 주류 소프트웨어 개발에 적용되는 표준 및 메트릭은 신경망 프로젝트에 실제로 적용 할 수 없습니다 (하드웨어에 대한 별도의 개발 프로세스 필요).

둘째, ANN을 별도의 주체로 취급하는 것이 사전 예방 적 위험 관리 형식입니다. 특히, 이는위험 구획화로 효과적으로 생각할 수있는 일종의 위험 이전입니다. 신경망 개발 프로세스와 관련된 위험은 신경망 개발 활동에 국한됩니다.

여기에 제시된 모델은 나선형 모델보다 폭포 개발 모델과 더 유사합니다. 이것은 일반적으로 나선형 모델을 포함하는 위험 관리에 대한 현재의 생각과 일치하지 않는 것 같습니다. 이 백서에 제시된 모델의 초기 화신은 개발 단계를 엄격히 선형으로 안내해야했습니다. 실제로, 접근 방식이 만족스러운 결과를 얻지 못할 때 프로젝트에서역 추적하는 쉬운 방법을 허용하지 않았기 때문에 이는 어색한 것으로 판명되었습니다.

이것은 현재 모델에서 두 개의 피드백 루프로 해결되어 프로젝트 피옴이 비생산적인 경로에 빠져들지 못하게합니다. 이는트레이닝 및 테스트 루프독립 테스트 및 검증에서데이터 수집 및 전처리로 돌아가는 피드백 루프에서 그림 1에서 볼 수 있습니다.

이것들은 ANN 모델에 나선형 모델의 가장 강력한 측면 중 일부를 추가합니다. 더욱이, 나선형 모델이 횡단되는 방식은 신경망 훈련 및 개발에서 수용된 단계와 잘 맞지 않습니다. 스파이럴 모델의 루프는 각각 소프트웨어 개발 프로세스의 한 단계에 해당하며 일반적으로 ANN 개발에 필요한 역 추적을 허용하는 명시 적 피드백 메커니즘이 없습니다. 나선형 모델의 여러 프로토 타이핑 측면이이 모델에 중첩 된 훈련 및 테스트 루프의 형태로 존재합니다.신경망 개발 프로세스의 내포 된 루프 모델 인이 프로세스 모델은 모든 유형의 중요 애플리케이션에서 사용하기에 충분히 완벽하도록 설계되었습니다.

그러나 프로세스의 정확성은 문서의 정확성 및 실제로 필요한 문서 측면에서 프로젝트에 맞게 조정되어야 합니다.

예를 들어 덜 중요한 응용 프로그램의 경우 모든 데이터 파일의 전자 복사본을 첨부하기위한 요구 사항이 완화될 수 있습니다. 식품 의약국 (Food and Drug Administration)은 문서 세부 프로세스 및 문서 요구 사항 [7]에서 소프트웨어와 관련된관심 수준에 따라 세 가지 문서 세트를 요구합니다. 따라서 의료 기기의 모든 소프트웨어가 중요하지만 일부는 다른 소프트웨어보다 중요합니다.

결론적으로, 프로세스가 조직을 위해 효과적으로 운영 되려면 수행될 수 있는 모든 프로젝트에서 적절하고 효율적으로 작업할 수 있을 정도로 유연해야 합니다.

인공 신경망 개발을 위해 이 문서에 설명된 프로세스를 사용하면 일관성, 노력의 반복성 및 긍정적인 위험 관리를 보장하면서 신경망 구성의 실험적이고 창의적인 특성을 계속 유지할 수있는 템플릿이 제공됩니다.

 

 

How many training set are enough in the Machine learning verification/validation?


I’m reading a paper whose title is “Autonomous Vehicle Safety: An interdisciplinary challenge”. This posting tells a story about my previous experience and prospect a future of machine learning verification.

I don’t know about machine learning, so I cannot ensure that my idea is true. Anyway when I read this paper, an idea occurred and I’d like to share a story in my Ph.d course.

I was studying finite state machine (or automata) and trying to solve test case generation for black box system. There are so many versions of automata to behave same system’s behavior. For example, Optimal automata can be made with 3 states and 4 transitions, while non-optimal automata can be made with 4 states and 5 transitions.

Guess that we want to test black box system and want to generate test cases. How many test cases are enough? Is it a sound to reason that system under test is optimally implemented? Because I cannot see inside of the system, I have to guess. I guess that it is optimally produced with 3 states and 4 transitions. But what if it is actually produced with 10 states and 24 transitions? Test cases that I generate based on optimal model, I just partially cover the real target. Why this problem is occured? it is because I don’t see inside of the blackbox. If I see inside(whitebox), then I can have a idea to make decision.

At that time, I felt such as I were in a cave in a dark. There was no light. This story ends with a new perspective, which is specification based testing and white box approach. As you know, in the SW testing theory, there are criteria for making decision when to stop. They are statement coverage, branch coverage, and MC/DC coverage.

I think that machine learning verification might be similar to this case. If we consider that it is blackbox inside of machine learning system, then we might not solve this problem. But we we understand and see inside of the machine learning mechanism, then we can suggest criteria when to stop to verify.

I really like to learn machine learning area, and want to study verification area. You can suggest me how to start.