Image Clustering Conditioned on Text Criteria

Introduction

Image clustering은 unsupervised learning task으로 연구되어 왔으며 대량의 visual data 구축, label이 없는 image dataset의 labeling 비용 감소, image 검색 system 성능 향상에 사용되었다.
최신의 deep image clustering 방법들은 ground truth로 간주되는 dataset의 사전 정의된 class label으로 종종 평가된다.

하지만 실제로는 각 사용자들이 동일한 dataset에 대해 clustering할 때 서로 다른 기준에 따라 여러 결과를 원할 수 있다.
그럼에도 기존 clustering 방법은 사용자가 clustering 기준을 제어할 수 있는 직접적인 mechanism을 제공하지 않는다. (기존 clustering 방법의 기준은 neural network의 inductive bias, loss function, data augmentation, feature extractor에 의해 결정될 가능성이 높다.)
따라서 저자들은 이러한 한계점을 개선하기 위해 사용자가 지정한 기준을 기반으로 단일 dataset에서 다양한 결과를 가능하게 하고 기존의 암묵적으로 지시된 clustering process를 혁신한다.

SOLAR 10.7B: Scaling Large Language Models with Simple yet Effective Depth Up-Scaling

Introduction

NLP 분야의 언어 이해와 상호작용에 대한 향상시킨 LLM의 도입으로 큰 변화가 진행되고 있다.
이러한 발전은 performance scaling law에 의해 더욱 큰 model 학습의 필요를 증대시켰다.
Mixture of experts (MoE)와 같은 방법을 통해 효율적이고 효과적이게 LLM을 scale-up을 할 수 있지만 종종 특별한 변화가 필요하여 광범위한 적용이 어려운 한계점이 존재한다.
따라서 효과적이고 효율적이게 LLM을 scaling up하며 사용 편의성을 위한 단순성을 유지하는 것은 매우 중요하다.
본 논문의 저자들은 sparse upcycling에 영감을 받아 효과적이고 효율적이며 단순한 LLM up-scale 방법인 depth up-scaling (DUS)를 제안한다.

Introduction

Upstage에서 진행하는 “Jump into the AI World - AI Production Lifecycle“ 강의의 홍보대사로 선발되어 해당 강의를 수강할 수 있는 감사한 기회를 얻게되었습니다.

Introduction

Jenkins를 통해 GitOps 기반으로 Docker image가 빌드되고 Docker Hub에 push 되게 하려면 아래와 같은 여러 방식이 존재한다.

	Docker-in-Docker (DinD)	Docker Outside of Docker (DooD)	Kaniko
Definition	Container 내부에 별도의 Docker daemon 실행	Host의 Docker daemon을 사용	Docker daemon 없이 container image 빌드
Security	더 높은 격리 제공, 하지만 보안상의 우려도 존재	Host Docker와 직접적인 상호작용으로 보안상 취약할 수 있음	Docker daemon 없이 작동하여 보안 강화
Performance	성능 overhead 가능성	일반적으로 더 나은 성능	Docker daemon을 사용하지 않기 때문에 성능이 최적화될 수 있음
Complexity	설정과 관리가 더 복잡	상대적으로 간단한 설정	환경 설정에 따라 다르나, 일반적으로 설정이 간단함
Used Tools	Jib, Buildah	Docker CLI, Docker Compose	Kaniko CLI, Kubernetes와의 통합
Suitable Use Cases	격리된 환경에서의 독립적인 container 관리	간단한 CI/CD pipeline 구성	Cloud 환경 및 Kubernetes에서의 image build

Introduction

자주 사용하는 Python 함수들을 package로 생성하고 CI/CD pipeline을 Jenkins로 구축하여 자동으로 배포될 수 있게 해보자!
배포는 package 내부의 함수 및 객체를 sphinx로 문서화하고 PyPI (Python Package Index)에 업로드하여 pip로 설치할 수 있게 해볼 것이다.
CI/CD 계획은 아래와 같다.

• Dev Branch Push
  1. Lint
  2. Build
  3. Test
• Master Branch PR
  1. Lint
  2. Build
  3. Test
  4. Docs
• Master Branch Puah
  1. Build
  2. Deploy
     1. PyPI
     2. GitHub

이 사항들을 Jenkins로 개발하고 blue ocean으로 확인해보면 아래와 같이 구성된다.