기본이 중요하다 [prompt]

_posts/2024-08-17-Kubernetes.md

@@ -0,0 +1,77 @@
+---
+
+title: 쿠버네티스 공식문서 정복하기
+date: 2024-08-17
+categories: [Kubernetes]
+tags: [Kubernetes]
+layout: post
+toc: true
+math: true
+mermaid: true
+
+---
+
+# 참고자료
+
+- [Kubernetes 공식문서](https://kubernetes.io/ko/docs/concepts/overview/)
+
+---
+
+# Kubernetes란 무엇인가
+
+좌측부터 온프레미스 -> VM -> Container 기반의 배포 방식을 나타낸 그림이다.
+
+![](https://kubernetes.io/images/docs/Container_Evolution.svg)
+
+컨테이너와 가상 머신은 모두 리소스 가상화 기술이지만 차이점이 있다. [Container vs VM](https://www.atlassian.com/microservices/cloud-computing/containers-vs-vms)
+
+| 특성 | 가상 머신 (VM) | 컨테이너 |
+|------|----------------|----------|
+| 가상화 수준 | 하드웨어 계층까지 전체 머신을 가상화함. 각 VM은 자체 운영 체제를 포함한 완전한 컴퓨터 시스템을 에뮬레이션함 | 운영 체제 수준 위의 소프트웨어 계층만 가상화함. 호스트 OS 커널을 공유하면서 애플리케이션과 그 종속성만을 포함함 |
+| 리소스 효율성 | 각 VM이 자체 OS를 실행하므로 더 많은 시스템 리소스를 사용함. 일반적으로 크기가 몇 GB에 달할 수 있음 | 호스트 OS를 공유하므로 더 가볍고 효율적임. 일반적으로 크기가 몇 MB 정도임 |
+| 시작 시간 | 전체 OS를 부팅해야 하므로 시작하는 데 몇 분이 걸릴 수 있음 | 초 단위 또는 그 이하로 매우 빠르게 시작할 수 있음 |
+| 격리 수준 | 완전한 격리를 제공함. 각 VM은 독립적인 시스템으로 작동하므로 보안 측면에서 강점이 있음 | OS 커널을 공유하므로 VM보다 격리 수준이 낮음. 하나의 컨테이너가 손상되면 다른 컨테이너에 영향을 미칠 가능성이 있음 |
+| 이식성 | 이식성이 있으나, 크기가 크고 다른 하이퍼바이저 환경으로 이동할 때 호환성 문제가 발생할 수 있음 | 매우 이식성이 높음. 동일한 OS 커널을 가진 어떤 시스템에서도 쉽게 실행할 수 있음 |
+| 개발 및 배포 | 개발 및 테스트 환경을 정확히 복제하는 데 유용하나, 생성과 관리에 더 많은 시간과 리소스가 필요함 | 빠른 개발, 테스트, 배포 주기에 적합함. CI/CD 파이프라인에 쉽게 통합될 수 있음 |
+| 용도 | 서로 다른 OS를 실행해야 하거나, 완전한 격리가 필요한 경우, 또는 특정 하드웨어 구성을 에뮬레이트해야 할 때 적합함 | 마이크로서비스 아키텍처, 클라우드 네이티브 애플리케이션, 확장 가능한 웹 서비스 등에 이상적임 |
+
+빠르게 애플리케이션을 포장하고 배포할 수 있는 컨테이너 방식이 채택되는 최근 추세에 따라 이 컨테이너들을 전체적으로 관리할 수 있는 오케스트레이션인 쿠버네티스가 중요해졌다. 공식문서에서도 아래와 같은 이유로 쿠버네티스가 필요하다고 한다.
+
+> 그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리할 수 있다.
+
+---
+
+# Kubernetes가 제공하는 것과 아닌 것
+
+## 쿠버네티스가 제공하는 것
+
+1. 다양한 워크로드 지원 (stateless, stateful, 데이터 처리 등)
+2. 서비스 디스커버리와 로드 밸런싱
+3. 스토리지 오케스트레이션
+4. 자동화된 롤아웃과 롤백
+5. 자동화된 빈 패킹 (리소스 최적화)
+6. 자동화된 복구 (self-healing)
+7. 시크릿과 구성 관리
+8. 메트릭 수집 및 노출 메커니즘
+9. 선언적 API
+10. 독립적이고 조합 가능한 제어 프로세스
+11. 현재 상태를 의도한 상태로 지속적으로 조정하는 기능
+
+## 쿠버네티스가 제공하지 않는 것
+
+1. 소스 코드 배포
+2. 애플리케이션 빌드
+3. CI/CD 워크플로우
+5. 로깅, 모니터링, 경보 솔루션
+6. 기본 설정 언어/시스템 강제
+7. 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템
+8. 중앙화된 제어 시스템
+
+---
+
+# Kubernetes Component
+
+- 쿠버네티스를 배포하면 클러스터를 구성하게 된다. 클러스터는 컨테이너를 실행하는 한 개 이상의 `워커 노드`를 가지고있다.
+- 워커 노드는 하나의 애플리케이션을 서비스하기 위한 컨테이너를 묶은 `파드`를 호스팅한다.
+- 그리고 워커 노드와 파드 내의 컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어 `컨트롤 플레인`이다.
+

_posts/2024-08-30-prompt.md

@@ -0,0 +1,127 @@
+---
+
+title: LLM과 친해지기
+date: 2024-08-30
+categories: [LLM]
+tags: [LLM]
+layout: post
+toc: true
+math: true
+mermaid: true
+
+---
+
+[모든 내용은 이 링크로부터 발췌함 - 당근 ML 밋업](https://www.youtube.com/watch?v=NzxlIGPbICY)
+
+---
+
+## 실시간 LLM 파이프라인을 위해서라면?
+
+- 좋은 프롬프트를 만들어야 한다.
+- 반복된 실험과 평가가 핵심
+    - 평가 데이터셋 마련하기
+    - 중요한 엣지 케이스 포함하고 보완하기
+        - 자동화된 배치 평가 파이프라인 마련하기
+    - 배치 평가 파이프라인
+        - 평가 데이터셋에 배치 평가와 프롬프트 개선 반복하기
+    - 프로덕션 파이프라인
+        - 프로덕션 실시간 인퍼런스
+        - 온라인 지표 모니터링
+        - 샘플링 분석으로 프롬프트 개선
+- 좋은 프롬프트를 만드는 노하우를 체계화하기
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/3.png?raw=true)
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/4.png?raw=true)
+
+- 구분자로 구조를 명확하게표현하기
+  - 마크다운 문법 사용하는 것도 도움이 된다.
+  - XML 스타일 태그또한 도움이 된다.
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/5.png?raw=true)
+
+- 요구사항을 구체화하기
+  - 예) 여러 필드를 가진 사용자 데이터에서 개인정보를 개인정보가 무엇인지 어떻게 제거하고 싶은지 세부사항을 명확하고 구체적으로 지시하기
+  - 미쳐 생각하지 못한 요구사항을 발견 시 피드백을 통해 강화해나가기
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/6.png?raw=true)
+
+- 예시 활용하기
+  - 예시를 과하게 주면 안된다. 그 예시에 편향된 데이터를 뱉을 확률이 높아지기 때문이다.
+  - 예시는 제한적으로 사용하기
+
+---
+
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/7.png?raw=true)
+
+- 생각하고 말하게 하기
+  - 바로 결과를 생성하게 하기보다 단계별로 사고 과정을 작성하도록 한다
+  - Chain of Thought Prompting (CoT)
+    - Constrastive Chain Of Thought
+  - 사용자 인풋을 바로 처리하지 않고 한번 생각하고 말한다.
+  - 결과를 단순히 말하게 하지 말고, 추론한 이유까지 말하게 하기
+  - 요약을 먼저 하고 분류하기
+  - 조건을 먼저 판단하고 조건에 따라 처리하게하기
+- Pseudo-Code로 지시하기
+- 지사사항과 사용자 입력의 순서도 영향을 준다
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/9.png?raw=true)
+
+- LLM도 요구사항이 컨텍스트가 길면 까먹는 경우가 있다. 따라서 중요한 요구사항이라면 뒤에 배치하는 것도 좋은 방법이다.
+- field 이름도 영향을 준다
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/10.png?raw=true)
+
+- 잘 모르면 지어낸다 (할루시네이션)
+- 조건을 벗어나거나 예외인 경우 어떻게 처리할지 알려주는 것도 좋다.
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/12.png?raw=true)
+
+- 다시 데이터로 활용하기 위해선 특정 형식으로 출력하게 하기 (json)
+- LLM이 json 형식으로 줘도 원하는 형태에서 벗어나는 경우는 후처리한다.
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/114.png?raw=true)
+
+- 실패를 대비하기
+    - LLM API도 장애날 수 있다.
+    - 프로덕션이 의존하고 있다면 장애에 대비
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/15.png?raw=true)
+
+- 모델 수명 고려하기
+  - 기존 버전은 제한된 수명을 가진다. (마치 언어 LTS 버전 유무 처럼)
+  - 모델의 수명을 반드시 확인해야 한다.
+  - 성능 평가 후 프롬프트 수정을 통해 성능을 유지해야 한다.
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/16.png?raw=true)
+
+- 사용량 고려하기
+  - LLM API 사용량 제한하기
+  - 그렇지 않는다면 모든 파이프라인의 장애로 이어질 수 있다.
+
+---
+
+![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/prompt/17.png?raw=true)
+
+- 서비스와 기능의 성공에 집중하기
+  - 구축하려는 서비스 또는 기능의 성공
+  - 프로덕션에 성공을 측정하는 지표 관찰 및 집중 - 모니터링에 초점을 맞추기.