run pod credit 관련 제보

안녕하십니까, 앗, 그런일이 있으셨군요. 근데 $5 크레딧이 반드시 주어지는지 잘 모르겠습니다. 제가 여러번 테스트 해봤는데, 먼저 가입을 한 상태에서 refer url를 입력하면 주어지지 않습니다. 미 가입 상태에서 refer url을 통해 들어가면서 가입해야 되는 것 같습니다(확실한 건 아닙니다만, 여러번 테스트 했을 때 미 가입 상태에서 refer url 통해 들어가야 $5가 추가 되었던 것 같습니다) 감사합니다.

Update(수정)용 모델 질문 드립니다.

안녕하십니까, 강의가 도움이 되었다니 저도 기쁘군요 ^^업데이트 코드 스타일이 정해진 표준은 없습니다. 물론 좋은 방법들은 있을 순 있지만, 이는 적용 환경별로 달라질 수 있습니다. 질문 범위가 명확하면 제가 답변 드리는게 더 도움이 될 것 같습니다만,예를 들어 "그래서 모든 필드를 Optional로 설정하여 부분 수정을 허용하게 하면 벨리데이션(Validation) 로직이 복잡해지는 문제가 발생했습니다." 라고 하셨는데, 어떠한 필드들을 update 속성들로 설정하셨고, 어떻게 수정을 허용해서 어떠한 검증 로직이 복잡해졌는지 예시를 부탁드립니다. 일반적으로 많은 필드들의 수정 시 이에 대한 검증 로직은 이뤄질 수 밖에 없습니다. 근데, 단순하게 자릿수라든지, 필드 타입이라든지, 공란등의 검증 정도를 복잡하다고 말하시는 건지, 아님 다른 부분을 의미하시는 건지 사례로 말씀해 주시면 좋을 것 같습니다. 감사합니다

딥러닝 강의 사전지식에 대한 질문

안녕하십니까, 물론입니다. 딥러닝 강의 시작하셔도 좋을 것 같습니다. 들으시다가 이해 안되는 부분이 있으시면 언제든 질문해 주십시요. 감사합니다.

length_penalty 부분이 없는 것 같습니다.

안녕하십니까, 아, 이걸 설명하는 걸 빼먹었군요. 알려 주셔서 감사합니다. 일단 글로 먼저 말씀드립니다. 추가 영상은 시간이 나는대로 작성하겠습니다. single_translate_beam() 과 같은 decode 시 고려해야 할 사항이, 문장을 생성하는 토큰들이 늘어날 수록 토큰 생성 확률(확률값은 1보다 작음)을 곱하게 되어서(여기서는 로그 확률로서, 확률값이 1보다 작아서, 로그 확률은 음수값이 됨) 토큰 개수가 작은, 짧은 길이의 문장들만 선호되는 현상이 발생하게 됩니다. 이를 개선하기 위한 방식이 짧은 길이의 문장들은 penalty를 주는 방법인데, 일반적으로 누적 로그 확률을 문장 길이(토큰 수, length)로 나누되, penalty 적용 강도를 적용 할 수 있도록 합니다. 이를 위해, 아래와 같은 length_penalty_fn() 함수를 통해 beam 선택 시 짧은 길이의 문장들은 penalty를 주되, alpha값으로 적용 강도를 조정합니다. def length_penalty_fn(length, alpha): return length ** alpha여기서 alpha가 바로 length_penalty 값입니다. final score filtering은 누적 로그확률 / length_penalty_fn 함수 반환값을 적용하게 됩니다. alpha가 0 이면 length penalty가 없으며(length ** alpha = 1임), a가 클수록 length penalty가 커집니다. 1로 설정하면 짧은 문장 편향은 사라지지만, 반복/미사여구 사용이 많아지는 과도한 보정이 됩니다. 1 이상은 사용하지 않고, 보통 0.6 ~ 0.8 정도 적용합니다. 결국 single_translate_beam(...)에서 sorted로 candidates 들을 key에서 정의한 lambda 함수, 즉 누적 로그 확률을 length_penalty_fn()으로 나눈 기준으로 sescending 정렬한 결과를 beam_width 갯수만큼 추출하여 최종 beams를 만들게 됩니다. beams = sorted( candidates, key=lambda x: x[1]/length_penalty_fn(x[0].shape[1], length_penalty), # x[1]은 누적 로그 확률. x[0][0] reverse=True, )[:beam_width] 감사합니다.

API 라우트 설계 시 중첩 구조 분리 기준 질문

안녕하십니까, 1. items나 users처럼 딱 떨어지는 리소스는 분리가 쉽지만, 실제로는 모델끼리 얽혀 있는 경우가 많아 라우팅이 모호해지곤 합니다.=> 딱 정해진 규칙은 없지만, 이 경우는 주체(주어가)가 무엇이냐에 따라 정하시면 좋을 것 같습니다. 가령 사용자(또는 고객, 계정)가 주체라면 사용자가 다른 오브젝트(또는 도메인)과 액션을 하더라도 이는 사용자 router로 정하면 됩니다. 예를 들어 특정 사용자가 선택(또는 구매)한 product들의 정보를 제공하는 API라면 /user router를 기반으로 서브 uri을 /user/{user_id}/products 을 정하면 좋을 것 같습니다. 마찬가지로 특정 category에 있는 상품정보를 제공하는 api라면 /product router를 기반으로 /product/{category_id} 를 지정하면 좋을 것 같습니다. 추가로 데이터 모델과 라우트 이름을 보통 같게 하나요?=> 데이터 모델과 일치 시킬 필요는 없습니다. 보통은 업무적인 개발 세부 도메인에 더 영향을 받습니다. 데이터 모델이 업무를 따라가는 경향이 있기 때문에 비슷하게 라우트 이름을 가질 수는 있지만, 데이터 모델에 종속될 필요는 없습니다. 감사합니다.

mmdetection 2.x과 3.x 호환 관련 표기

안녕하십니까,음, 이건 제가 도움을 드리기 어렵겠군요.강의는 2.x 기준이고, 제가 3.x를 잘 알지 못합니다.2.x와 3.x가 뼈대는 비슷하지만, 전체적으로 조금씩 변경되었습니다. 본 2.x 강의를 들으시면 3.x 적용하시는데 무리 없을거라 생각되지만, 어떤 부분을 어떻게 덜어내야 하는지는 저도 잘 모릅니다.감사합니다.

mm_faster_rcnn_train_kitti.ipynb 실행 오류

안녕하십니까, 지금 Kaggle에서 수행하는데 안되시는건가요? Kaggle에서는 여전히 수행이 잘 됩니다만, Colab에서 수행하시는 건지 Kaggle에서 수행하시는 건지 확인 부탁드립니다. Colab에서 수행하시면 Kaggle 수행 부탁드립니다.감사합니다.

table full scan과 index_ffs 성능비교

안녕하십니까, 주말에 일이 있어서 답변이 늦었습니다. table full scan이 index fast full scan 보다 빠른 경우는 거의 없을 것 같습니다. index ffs는 full scan 뿐만 아니라, 사이즈가 크면 direct io 까지 수행합니다. index 크기가 table 크기보다 크지 않으면(아주 예외적인 경우) index ffs가 더 빠릅니다. 감사합니다.

카프카 토픽 Key 타입 변경에 관한 질문

안녕하십니까, 이 실습 코드를 만들때 새로운 토픽으로 생성하는게 더 좋았을 것 같군요. --from-beginning으로 테스트 해보실 거라고는 생각하지 못했습니다 ^^네, 생각하신대로 --from-beginning으로 Integer Deserializer를 적용하면 이전에 String으로 Key가 들어가 있는 경우 Consumer가 제대로 Deserialization하지 못해서 오류가 발생합니다. 그리고 kafka console consumer 는 Deserializer를 지정하지 않으면 기본적으로 String Deserializer 로 설정합니다. 이때 Integer로 들어가 있는 Key는 String으로 Deserialization하는데 Integer가 아니라 숫자형 문자값으로 적용됩니다. 그래서 오류가 발생하지 않습니다. 토픽의 Key 타입을 중간에 변경하는 경우는 거의 없습니다. key 타입이 다르면 일반적으로 Topic을 새롭게 생성합니다. 감사합니다.

Kaggle 에서 Santander customer satisfaction data 를 다운로드 되지가 않습니다.

안녕하십니까, 앗, 그런 문제가 있었군요. 일단 https://github.com/chulminkw/various_data 에 가셔서 train_santander.zip 파일을 다운로드 받으신후 압축을 해제 하시고 사용하시면 될 것 같습니다. 감사합니다.