Core Tensorflow

Core Tensorflow

- Tensorflow → graph로 구성

- Rank4 3차원 cube 가 쌓여있는 상태로 이해할 수 있음(4차원)

- tensorflow에서의 rank 개념은 dimension의 개수에 대한 것이라고 이해

- tensorflow는 어느 devices에서도 적용 가능

- tensorflow1.x vs tensorflow2.0 좀 다름...나중에 자세히

- core tensorflow 부터 tf.estimator 까지 올라갈수록 조금 이해하기 힘들수 있지만 더 쉽게 접근 가능

- binary로 결과를 리턴하기 전에 그래프짜놓고 한방에 feed하는 방식(session)

- lazy evaluation을 피하고 바로 결과를 확인하기 위해서는 eager 모드를 사용하면 가능함

- eager 모드는 마치 numpy 같이 움직임

- gradient : 미분값(slope 반영)

- lazy evaluation을 하는 이유

  > 분산처리

  > 여러가지 graph를 나눠서 각각 분석하고 합칠수 있음(?)

- tensor graph를 만들때 name을 주는 것은 visualization을 할 때 좀 더 이해가 좋게 하기 위해 만듦(tf.summary.FileWriter, tensorboard 등)

- summary를 저장하고, tensorboard에서 이를 불러와서 시각화하는 것

- tensor의 모양에 대한 설명

- reshape할때 sequential 한 순서로 다시 shape을 짬

  > ex) x = [[3,5,7],[4,6,8]] -> reshape(x,[3,2]) → [[3,5],[7,4],[6,8]]

- vars() function을 이용하여 다양한 정보를 볼 수 있음

 

Debugging Tensorflow programs

- read error message -> 확인 : test를 하려면 데이터를 아주 작게 쪼갠 다음 실험해야함

- know how to solve common problems

- error 중 data type의 mismatch가 있기 때문에 placehold나 변수설정할때 type을 신경쓸필요 있음

- error를 확인할 수 있는 코드들 추가 : assert 조건, error message

- tensor shape를 위한 함수

- expand_dims(x,1): 1차원을 늘린다 <--> squeeze : 1차원을 줄인다

- tensorflow는 type에 민감하기 때문에 type을 맞추기 위해 tf.cast(x,tf.float32) 라는 함수를 사용함

- tf.Print 라는 함수를 통해 tensor에 있는 값들을 출력할 수 있음 

  > session 단계에서 적용해야 나타나겠지

  > ipython에서 실행 안될수도 있음

- sees 단계에서 wrapper로 디버깅을 만들어 놓고, 조건을 걸수 있음 infinite, nan값이 들어오면 가능

- tf.where(조건, False일때 실행시킬 것, True일때 실행시킬 것)

- jupyter 환경내에서는 볼 수 없음(terminal에 가서 그 파일을 실행시켜야함)

Tensorflow Estimator API

- estimator 는 high level 단계

  > machine learning을 product 시킬 때  많은 문제를 해결해줌

- sharding~~~

 

- baseline Regressor가 뭔가????

 

- tensorflow estimator workflow

 - feature를 만들어 놓고 model에 집어넣음

- estimator에 들어갈 feature를 형식에 맞게 만들어줘야함

- input_fn 생성 : return 값이 features, labels 리턴해야함

  > 여기서 feature 명은 앞에서 정의한 featcols 와 같은 이름이어야함

- 예측을 위해 predict+input_fn 도 생성, 여기서는 features 만 return 하면 되겠지

- predictions → 제너레이터 → 스트림한 데이터를 넣기 위해 → predict(x) 여기서 x가 데이터가 아니라 함수가 들어가는 이유임

- train 할때 scikit-learn 처럼 데이터를 바로 집어넣고 돌리게 만들지 않은 이유?

  > 번거로운 input generator를 만들어야하는 이유 → 분산처리를 하기 위해 placeholder와 같은 graph를 내부에서 만드는 것으로 보임

- 최종적으로 estimator를 쓰는 순서~~!

- model checkpoints

  > 모델이 학습중에 다운이 되거나 어떤 문제가 생겨서 끊어져?버리면 문제가 생기겠지

  > 또한 어떤 문제가 있었는지 기록을 볼 필요가 생길수 있지

  > 이를 위해 단계(계획된)에 따라 모델을 저장함 → checkpoint → variable, weight, bias, graph 등…

  > train 단계를 실행하면 저장된 위치에서 마지막 checkpoint 를 찾고 그것부터 다시 트레인을 하므로 상당히 효율적임

  

- numpy와 pandas 데이터 셋을 dataset으로 만들어 input_fn을 구성하는 방법

  > 여기서 queue_capacity는 메모리 관련된 문제를 막기위해 설정

     : queue 크기만큼 데이터를 가지고 와서 batch_size대로 batch를 나누고 모델에 feed함

     : queue 사이즈는 batch size의 10배정도는 해줘야 좋음(shuffle을 위해서)

-  dataset 넣을때 input_fn에서 epochs를 정해줄 수 있고, train단계에서도 몇번을 gradient decsent 할지 정할 수 있음(steps)

- batch가 너무 작으면...학습이 잘 안될 수 있음 batch문제로 loss 조금씩 웨이브를 탈 것이야. 결국 loss 변화의 trend(smoothing)을 보고 학습모델이 잘 학습되었는지 확인하는 것이 나음

- eval error가 train error보다 낫게 가는 경우>? 어떻게 해석?

  > 사실 그런 경우는 없을 것 같지만, 있을 경우, eval data가 특별할 수 있음, random sampling에서 좋은 data만 eval로 갈 수 있는 경우에 발생가능

- model을 만들때는 column lst를 넣고, train, evalution, predict할때는 data function을 넣음(argument)

- tf.data.Dataset.from_tensor_slices : generator 생성

  > x =[1,2,3], y=[4,5,6], z={‘f1’:x, ‘f2’:y}

from_tensor_slices(x) → 1 2 3	from_tensor_slices((x,y)) → (1,4) (2,5) (3,6)
from_tensor_slices(z) → {‘f1’:x0, ‘f2’:y0} {‘f1’:x1, ‘f2’:y1} {‘f1’:x2, ‘f2’:y2}	from_tensor_slices((z,Y)) → ({‘f1’:x0, ‘f2’:y0}, 4)  ({‘f1’:x0, ‘f2’:y0}, 5) ({‘f1’:x0, ‘f2’:y0}, 6)

- train 단계에서 lambda : input_fn을 이용하여 넣는 이유는 인자가 함수를 받게 설정되었기 때문

- 모델에 config = tf.estimator.RunConfig(tf_random_seed = 1) 을 넣는 이유는 여러개의 모델이 존재할 수 있기 때문에 config를 이용해 적용하는 것