AI를 1도 모르는 JAVA 개발자 입니다. AI를 어떻게 공부해야 하는지 몰라서 인프런 검색하여 강사님 강의를 듣게 되었습니다. AI 개발에 파이썬이 사용된다고 하여 인공지능을 위한 파이썬 Level4 까지 모두 구입해두고 듣고 있는데요. 개발자라서 지금 수업이 어렵거나 하지는 않습니다. 그런데 인공지능을 위한 파이썬 LEVEL4 수업이 끝나면 어떤 수업을 들어야 하는 걸까요? 강의를 듣다 보니 통계, 확률을 알아야 하는 것 같은데 저는 그것도 전혀 모릅니다. 이후 어떤 수업을 들어야 하는지 문의드려요.
안녕하세요 선생님. 오늘도 너무나 재밌게 잘 배우고 있습니다. 감사드립니다. 현재 시간 관계상, 섹션4(RCNN계열)까지 수강 후 섹션7(SSD)를 수강중입니다. 강의 내용을 누락시킨 채 질문을 드리는 것이 아니었으면 좋겠습니다. 제가 이해한 바 Faster-RCNN에서 RPN은 image 원본이 아닌 feature map을 입력을 받는다. RPN 내에서 Positive Anchor들에 대해서만 학습을 수행한다. 일 때 학습 시에, RPN내에서 특정 anchor의 Positive 판단이 된다면, 해당 anchor 위치에 어떤 객체 A의 GT가 IoU 기준에 부합하다는 것이 판단되어야 할텐데, RPN 내에서는 feature map 을 입력으로 받고 있으니 내부에서 A 객체의 GT와 anchor 의 IoU를 계산하기 위해선 GT(image 좌표계), anchor(feature 좌표계)를 비교해야 할 텐데 이건 너무 번거로운 일이 아닌가 생각이들었습니다. 위 내용이 틀렸다면 RPN 이전 벌써 anchor 가 존재하고(혹은 설계 가정), 매 학습 이미지가 들어올 때마다 각 anchor 의 라벨정보를 미리 구해놓은 뒤 역전파 시점에서 해당 라벨 정보를 가지고 RPN의 손실 함수 계산에 해당 라벨정보를 포함시킬 수 있겠다라고 생각을 했습니다. 하지만 이런 경우 이 anchor의 positive 처리 과정이 network 내로 들어올 수 없고 Keras 와 같은 framework 구성으로 들어와야하지 않을까 하는 생각이 들었습니다. network 에는 처리 소스코드를 넣을 수 없으니까요. (특정 구조로 가능할런지는 모르겠습니다) 질문입니다. RPN 내에서 Anchor Positive 처리가 이뤄지나요?
안녕하세요, 좋은 강의 항상 감사드립니다. runpod 방법으로 바뀐뒤 적용 후 학습을 해보는 과정에서 incredibles detect 실습과정에서 에러가 났다가 해결하여 제보드립니다. numpy 2.2.6버전으로 template에 깔려있어서 numpy .1.x 기준으로 컴파일된 다른 패키지가 서로 충돌이 일어나서 epoch 학습이 시작되지 않는 에러가 있었습니다. 전 깔끔하게 numpy를 삭제하고 다운그레이드한 뒤 해결하였습니다. # 수정전 # Runpod의 경우 GDrive 연결하지 않고 /workspace/ultra_workdir에 저장. !mkdir "/workspace/ultra_workdir" # 주피터 노트북에서 참조할 수 있도록 /workspace를 /content/workspace 디렉토리로 soft link 적용. !ln -s /workspace /content/workspace # 수정 후 !mkdir "/workspace/ultra_workdir" !ln -s /workspace /content/workspace !conda uninstall numpy --force -y !conda install numpy=1.26.4 -y
사용자가 캘린더를 보유했는지 여부로 확인할 것 같습니다. 이유는 추후 서비스 확장할 때 조금 더 수월할 것 같다는 생각이 들었습니다. 프로젝트를 시작하면서부터 아래와 같은 생각을 했습니다. - "누구나 호스트가 되면 안될까?" - "호스트 역시도 커피챗을 신청할 수 있게 하고 싶다." 그래서 위와 같이 서비스 정책을 확장할 때를 대비해서 (마이그레이션 비용을 줄이는 방향으로) is_host로 검사하는 것이 아닌 일단 캘린더 보유 여부로 호스트인지 아닌지 확인하자라고 판단했습니다.
두 요소를 모두 사용 하나, 각각 다른 용도로 쓸 것입니다. is_host 용도: 호스트 전용 엔드포인트 접근 통제 및 UI 메뉴 노출, 권한 기반 라우팅 호스트를 위한 endpoint API 에 대한 이용 허가 여부를 결정하는 호스트의 access token 생성 및 엔드포인트 함수 내의 조건문을 위해 필요한 모델 필드라고 생각합니다. 예상되는 우려점은 호스트 유저가 더이상 host가 되지 않을 때, host를 위한 API의 이용 허가를 거부 해야하기 때문에 is_host 필드값의 확실한 업데이트가 필요합니다. 사용자 캘린더 보유 여부 용도: 실제 예약 생성/동기화가 필요한 시점에 필수 체크, 호스트의 온보딩 플로우의 완료조건 게스트의 성공적인 Booking 을 위해서는 실제 캘린더에 대한 접근이 필요하기 때문에, 호스트는 게스트가 Booking 하기 위해서는 캘린더를 무조건 보유해야 합니다. 예상되는 우려점은 호스트의 캘린더는 호스트가 Booking을 받을 준비가 되있다면 항상 존재 해야하며, 실제 올바른 호스트에 매핑이 되어야합니다. 만약 캘린더가 존재 하지않거나, 호스트 캘린더 ID 에 대한 검증이 제대로 동작 하지 않는다면, 게스트의 Booking 이 실패로 이어지거나 다른 호스트 캘린더에 등록이 될 수 있습니다.
중복 예약을 데이터베이스의 고유값 제약으로 예방하는 방법 조건은 1)동일 일자와 동일 타임 슬롯인 경우 중복으로 간주 2)약속(부킹)이 취소되어 attendance_status 모델 필드값이 cancellled인 경우 예약 가능 위를 구현하기 위해 데이터베이스에게 아래 정보가 고유해야 한다는 특별한 규칙을 알려줄 수 있습니다. 1)누가 예약하는지 2)언제 예약하는지 3)어느 시간대에 예약하는지 위의 세가지가 모두 같으면 중복 예약이라고 판단 합니다. 취소된 재예약은 가능하게 하기 위해 고유성 규칙에 한가지 예외를 부여합니다. 호스트, 날짜, 시간 슬롯의 조합은 고유해야 한다. 예외적으로 예약상태가 "취소됨"이라면 그 예약은 위의 고유성 규칙을 무시해 달라고 합니다. 새로운 예약 생성 시: 데이터베이스는 예약하려는 호스트, 날짜, 시간슬롯 정보를 보고, 현재 '취소됨' 상태가 아닌 다른 예약이 이미 있는지 찾아봅니다. 만약 '취소됨' 상태가 아닌 다른 예약이 이미 같은 자리에 있다면, 데이터베이스는 "안돼! 이미 예약된 자리야!"라고 하며 새로운 예약을 저장하지 못하게 합니다. 만약 같은 자리에 '취소됨' 상태가 아닌 예약이 없다면, 데이터베이스는 새로운 예약을 성공적으로 저장합니다. 예약 취소 시: 어떤 예약이 '취소됨(cancelled)' 상태로 변경되면, 데이터베이스의 이 "특별한 규칙"은 그 취소된 예약을 더 이상 고유성 검사 대상에서 제외 합니다. 이제 그 자리는 "비어있는" 것처럼 간주되므로, 다른 사람이 같은 호스트, 날짜, 시간슬롯 정로 새로운 예약을 만들 수 있게 됩니다.
사용자가 호스트인지 두 가지 방법으로 확인 가능합니다. 1. User 모델에 선언한 is_host 모델 필드가 True인지 확인 2.사용자가 캘린더를 보유했는지 확인 이 중 두 가지 방법 모두를 사용해야 한다고 생각합니다. 1. User 모델에 선언한 is_host 모델 필드가 True인지 확인 -> 관점적 측면에서 명시적이고 관리적인 역할 및 자격을 부여합니다. 즉 사용자가 호스트로 자격이 있다는 것을 의미합니다. 관리자가 특정 사용자를 호스트로 지정하거나 해제하는데 사용할 수 있고 캘린더의 유무와 별개로 관리가 가능하게 서비스의 효율을 향상시켜 줍니다. 2.사용자가 캘린더를 보유했는지 확인 ->실제 예약 요청이 들어 왔을 때 해당 호스트가 유효한 캘린더를 보유하고 있는지 확인하는 최종적인 역할을 할 수 있습니다. 즉 위의 두 정보가 모두 필요한 이유는 존재하지 않는 사용자의 username으로 캘린더 정보를 가져오려고 하거나 호스트가 아닌 사용자의 username으로 캘린더 정보를 가져오려고 하는 시도를 막을 수 있을것으로 예상됩니다. 요약하면 is host는 "호스트로서의 신분"을, 캘린더 보유 여부는 "호스트로서의 활동을 나타내는 정보여서 모두 필요합니다.
캡차 응답을 확인할 수 없습니다. 문제 해결 정보는 https://docs.github.com/articles/troubleshooting-connectivity-problems/#troubleshooting-the-captcha 를 참조하세요. 위와 같이 메시지가 뜨는데 회사나 기관의 네트워크을 사용하라고 하는데 꼭 고정IP를 사용해야 하는 건가 해서요. 집이나 도서관 등 유동IP는 사용이 불가능한 건가요?
제목 그대로 쇼츠에 올릴 영상 5개를 만들기 위해서 이미지 생성을 하면 이미지가 너무 많이생성이 됩니다. 처음에는 제가 잘못했나 싶었는데 2번째 생성시도했을때는 이미지가 122개가 생성이되네요.. ( REQUEST로 확인했을때 정확하게 세보지는 않았지만 중복된 이미지가 많았습니다) 어디가 문제일까요 ..? (이미지 마다 눌러서 URL 복사해서 유튜브 자동화 시트에 붙여넣기 하면 영상생성은 잘됩니다)
데이터베이스 고윳값 제약으로 예방하는 구현에 대해서 조사했습니다. 동일 일자와 동일 타임슬롯인 경우 중복 Booking에 unique index를 생성하는 것인데 동일 일자 (when)과 동일 타임슬롯(time_slot_id) 조건을 생성하면 됩니다. CREATE UNIQUE INDEX uq_booking_slot ON bookings (when, time_slot_id); class Booking(SQLModel, table=True): __tablename__ = "bookings" __table_args__ = ( UniqueConstraint("when", "time_slot_id", name="uq_booking_slot"), ) attendance_status 필드값이 cancelled인 경우 PostgreSQL의 경우 partial unique index가 가능합니다. where를 사용해서 field가 cancelled가 아닌 경우에 unique 제약을 걸면 됩니다. CREATE UNIQUE INDEX uq_booking_slot ON bookings (when, time_slot_id) WHERE attendance_status <> 'cancelled' ; class Booking(SQLModel, table=True): __tablename__ = "bookings" __table_args__ = ( UniqueConstraint("when", "time_slot_id", name="uq_booking_slot"), postgresql_where=text("attendance_status <> 'cancelled'") ) 다중 컬럼에 대한 unique는 종종 사용하는 방법이었는데 where를 이용해서 조건을 설정할 수 있는 건 이번에 첨 알았습니다. 필요하면 python에서 처리하곤 했었는데 데이터베이스 기능으로 이용하는게 레이스 컨디션도 피할 수 있고 장점이 있어보이네요. 실무에 적용할때도 꼭 이용해보겠습니다.
파일 삭제 정책 booking을 삭제할때 해당 booking과 업로드된 파일을 같이 삭제하는 정책 의미없는 파일이 남아있는 것은 저장 공간 낭비 유출 위험을 줄여준다(?) (예: 삭제된 booking의 파일을 남겨두어 총 100개의 파일이 저장된 상태라고 가정. 그 중에 70개는 필요한 파일, 나머지 30개는 필요없는(삭제된 booking) 파일임. 파일을 바로 제거하지 않아서 100개가 다 유출되는 것보다 의미없는 파일을 바로바로 제거하여 70개만 유출되는 것이 더(?) 낫다..) 그러나 한편으로는 트래픽이 적은 시간에 삭제된 booking의 파일을 주기적으로 정리하는 로직을 실행하는 것이 더 나을까 하는 생각도 드네요