쿼리 질문있습니다!!

안녕하십니까, 아래와 같은 이유로 generate_series()를 사용했습니다.연속된 날짜 데이터를 얻기 위해서 굳이 ga_sess 테이블에 group by까지 적용한 부하가 큰 SQL을 사용할 필요는 없습니다. generate_series()를 이용하면 빠르게 해당 집합을 만들 수 있습니다. select date_trunc('day', visit_stime)::dateascurr_datefrom ga_sessgroup by date_trunc('day', visit_stime))데이터의 특성 상 아주 희박하지만, 혹시나 ga_sess에 visit_stime group by visit_stime 시 빠지는 날짜가 발생할 가능성이 있습니다(시스템이 다운되어서 사용자가 아예 안들어오는 기간이라던가)감사합니다

join 관련 질문 (inner join, left join)

안녕하십니까, 어떤 부분이 잘 감이 잡히지 않는지 말씀해 주시면 제가 답변이 좀 더 수월할 것 같습니다만, 먼저 inner join은 두개의 테이블을 조인할 때, 서로 매핑되는 조인키가 없으면 결과를 추출하지 않습니다. 즉 두개의 테이블의 조인키값이 서로 같은 경우에만 조인에 참여할 수 있고 결과를 추출합니다. 하지만 두개의 테이블이 서로 조인키 값이 같지 않더라도(즉 조인에 참여하지 않더라도) 결과를 추출해야 하는 경우가 있습니다. 그래서 SQL에서 left join, right join, full outer join이 만들어지게 됩니다. 그리고 left join은 두개의 테이블이 서로 조인키 값이 같지 않더라도, 조인을 시작하는 테이블, 즉SQL 의 LEFT JOIN 문장의 왼쪽에 있는 테이블을 결과를 여전히 추출해 줍니다. 질문에서 "강사님께서 조인을 선택해서 사용하실때 기준이 있을까요??" 라고 하셨는데, 이게 어떤 의미인지 제가 잘 이해하지 못했습니다. 물리적인 기준은 앞에서 말씀드린대로(그리고 강의에서 말씀드린대로 ) 적용하시면 됩니다. 업무적으로는 주로 Master 테이블(가령 고객, 계좌등)과 다른 테이블을 조인하는데, 조인 키가 없더라도 Master 테이블의 레코드는 여전히 추출해 주는 경우등이 있을 것입니다(예를 들어 고객과 주문 테이블을 조인할 때 주문이 없는 고객이더라도 여전히 고객정보는 추출해 주는 경우등)Left Join이 반드시 부모-자식간의 테이블에만 적용하는 것은 아닙니다. 부모와 자식 테이블간 조인을 하는데, 조인값이 매핑되지 않더라도 부모 테이블의 정보를 추출하는 업무적인 요건들이 많아서 그럴 뿐 해당 경우에만 국한되는 것은 아닙니다. 명확하게 부모-자식 테이블간 조인이 아니어도 left 쪽에 위치한 테이블의 정보를 그대로 유지하려는 경우에 적용될 수 있습니다. 그리고 일반적으로 부모-자식간 관계는 1:M이 가장 많지만, 1:1이 되는 경우도 있습니다. 자식 테이블이지만, 부모 PK 레벨로 단 한건의 고유 데이터가 생성되는 자식 테이블도 있을 수 있습니다. 감사합니다.

mm_faster_rcnn_train_coco_bccd 실행 오류 질문드립니다.

안녕하십니까, 강의를 잘 듣고 계시다니 저도 기분이 좋군요. 정확한 원인은 아닐 수도 있지만, mmdetection의 2.x 버전과 numpy 버전, coco 버전 등의 현재 호환 이슈등으로 train_detector(model, datasets, cfg, distributed=False, validate=True)호출 시 validate=True로 해서 validation data의 evaluate를 수행하면 오류가 발생합니다. 아쉽게도 현재는 train_detector(model, datasets, cfg, distributed=False, validate=False) 와 같이 validate=False로 해서 validation data의 evaluation을 skip 해줘야 합니다. 감사합니다.

5강 강의 오류가 있어요.

안녕하십니까?접속하셨던 시점에 인프런 서비스 차원에서 뭔가 문제가 있었던것 같습니다. 현재 다른 음성 문제가 없습니다. 혹시 문제가 계속 발견되시면 몇분 몇초에서 그런건지 확인 부탁드립니다. 감사합니다.

배치에서 full outer join을 쓴다고 하셨는데 예시를 알 수 있을까요?

배치에서 쓴다라기 보다 효율적으로 사용할 수 있다라는 의미로 생각해 주시면 좋을 것 같습니다. 근데, 예시를 들기는 좀 사례가 복잡합니다. 배치 프로그램 고도화 영역에 해당한다고 보시면 되는데, 어떻게 보면 SQL튜닝이나 어려운 SQL 처리로직등을 포함하는 부분이라, 여기서 말씀드리기는 한계가 있습니다만, 그래도 대략적으로만 기술하면 배치에서는 주로 개별 데이터를 경우에 수에 따라 여러번 추출하는 경우들이 있는데, 가령 예를 들어 고객이 주체가 되어서, 고객으로 left outer 조인이 되는 집합 하나, 또 다른 경우 상품이 주체가 되어서, 즉 상품이 left outer 조인이 되는 집합 하나 각각 만들어서 개별 loop를 수행하면서 배치 처리를 하는 경우들이 발생하면서, 수행 속도의 저하와 로직의 복잡성이 발생할 수 있습니다. 이 경우 각각을 분리하지 않고, Full outer 조인으로 한번에 대상 집합을 만든 다음에 배치 처리를 하는 배치 개선화 프로세스에 사용 될 수 있습니다. 감사합니다.

Madrid에 살고 있는 고객이 주문한 주문 정보를 구할것. 실습 질문드립니다

안녕하십니까, 해결이 되었다니, 다행입니다. 감사합니다.

MLM, NSP 구현 여부

안녕하십니까, 고민은 했었는데, 전체 강의가 이미 충분히 Transformer에 대한 많은 내용을 다루고 있고, 전체 강의 구성 상 BERT는 해당 섹션에서 말씀드리는 내용만 이해하셔도 충분하다고 생각합니다. 또 강의 시간이 애초에 기획한 것보다 훨씬 길어져서, 여기에 MLM, NSP Pre- train구현까지 추가되면 강의가 늘어(?)지게 될 것 같아서 해당 내용은 담지 않았습니다. MLM, NSP의 Pretrain에 집중하는 것 보다는 이후 MarianMT에서 Encoder-Decoder 학습을 보다 빨리 접해 보시는게 더 도움이 될 것 같습니다. 감사합니다.

bert encoding input_ids.size(1)에 대하여

안녕하십니까, 좋은 질문이군요. BERT 모델의 Position Embedding의 max_len은 동적으로 입력되는 문장들의 최대 sequence length와는 다를 수 있는 상황을 고려해야 했기에 forward()에서 seq_len = input_ids.size(1) 적용한 것입니다. 예를 들어 시나리오와 같이, 짧은 대화형의 문장들은 BertTokenizer 적용할 때 padding='max_length', max_length=200를 설정할 수도 있고, 긴 연설문 문장들은 padding='max_length', max_length=1000 을 설정할 수도 있습니다. 또한 max_length를 적용하지 않고, padding='longest' 를 적용할 수도 있습니다. 그래서 일반적으로 Position Embedding의 max_len과 tokenizer의 max_length를 일치 시키지 않습니다. Position Embedding의 max_len은 모든 경우에 대해서 할당할 수 있는 최대 position 값이라고 생각해 주시면 됩니다. 감사합니다.

트랜스포머 학습 강의

안녕하십니까, 트랜스포머 모델의 학습(Train)은 이후 섹션인 BERT와 MarianMT에서 다루고 있습니다. BERT는 Encoder 기반, MarianMT는 Seq2Seq(Encoder-Decoder) 기반으로서 이후 섹션에서 BERT, MarianMT의 모델 구현 뿐만 아니라, Custom 데이터 기반으로 학습과 Inference까지 실습하는 내용으로 구성되어 있습니다. 감사합니다.

signed cookie 와 jwt 토큰

안녕하십니까, 강의 칭찬해 주셔서 감사합니다 ^^JWT와 Signed Cookie의 가장 큰 차이는 Signed Cookie는 웹브라우저 기반에서 쿠키 정보를 인증하는 것이고, JWT는 HTTP 프로토콜을 사용하기만 하면, 어떤 클라이언트에서도 인증을 수행할 수 있는 방식 입니다. 그러니까 Signed Cookie는 웹브라우저가 필요하고, JWT는 웹브라우저 뿐만 아니라 다양한 모바일 앱, 서버 To 서버, 사이트 To 사이트, IoT 디바이스 등에서도 인증을 수행할 수 있습니다. JWT가 이렇게 다양한 클라이언트에서 사용될 수 있는 이유는 JWT가 HTTP 헤더에 실어 보내는 Json 형태의 문자열일 뿐이기 때문입니다. 서버와 클라이언트가 HTTP 프로토콜로 통신만 할 수 있으면 편리하게 인증을 적용할 수 있습니다. JWT는 크게 3가지 요소를 가지는데, Header, Payload, Signature로 구성되어 있습니다. Payload는 주요 정보를 담고 있는데, Payload는 base64 인코딩만 적용되므로 중간에서 탈취되면 값을 확인할 수 있습니다. 그래서 JWT 자체에는 보안상 중요한 값, 예를 들어 Password, 신용카드정보, 계좌번호, 주민번호와 같은 값은 담지 않아야 되며, 주로 사용자 ID, 접근 권한, 만료 시간등의 정보를 가집니다.그렇다고 보안을 적용하지 않는 것은 아닙니다. 바로 JWT의 Signature와 JWT를 인증하는 서버에서 Signature 발급시 적용한 secret key를 기반으로 Signature가 변조되었는지 비교하는 단계가 있습니다. Signature가 서로 맞지 않으면, 인증을 허용하지 않습니다. JWT는 민감정보를 보관하기는 적절치 않은 단점은 있지만, HTTP 프로토콜을 사용하는 한 클라이언트 제한이 없다는 장점 때문에 API 기반의 인증이나, 카카오, 네이버, 구글등의 외부 제 3자 서비스 인증(OAuth2)에서 자주 활용됩니다. 감사합니다.