Tech News
최신 테크뉴스 트렌드
L
Lighthouse
AI가 인류의 삶에 어떤 변화를 가져올까요? 🤖✨ Dario Amodei의 에세이 *"Machines of Loving Grace"*는 생물학, 정신 건강, 거버넌스, 경제 발전 등 다양한 분야에서 AI가 선사할 긍정적인 변화에 대해 이야기합니다.
물론 위험 요소도 있지만, AI가 과학적 발견을 가속화하고 사회 발전을 이끌 수 있는 잠재력을 주목합니다. 🚀 이러한 변화를 잘 활용하는 것이 미래의 핵심입니다!
👍🏻
1 Reaction
Reaction
Comment
Share
L
Lighthouse
OpenAI vs. Anthropic 매출 비교 요약
1.
OpenAI는 매출 규모 면에서 5배 큼
연간 매출 기준 OpenAI는 Anthropic의 약 5배 규모(50억 달러 대 10억 달러)
하지만 Anthropic의 성장 속도가 더 빠름
연초에는 OpenAI가 Anthropic의 약 15배 규모였음
2.
ChatGPT는 단연코 지배적인 프로슈머 제품
Sonnet 등 Anthropic의 최신 모델과 Claude, Artifacts 등의 기능에 대한 관심이 높음에도 불구하고 ChatGPT 사용자 대다수는 Claude를 사용하거나 들어본 적이 없을 것임
매출 면에서 ChatGPT는 연말에 약 27억 달러를 가져올 것인 반면, Claude는 약 1억 5천만 달러 수준
매출 규모 면에서 ChatGPT가 약 18배 큼
Anthropic은 최근 기업용 Claude 버전을 출시했지만 ChatGPT는 이미 100만 명 이상이 고가 플랜(기업/팀)을 이용 중이라 크게 뒤처져 있음
3.
개발자 제품에서도 Distribution이 여전히 중요
Anthropic 매출의 약 65%가 제3자 API에서 발생한다는 점은 유통의 중요성을 보여줌
많은 벤치마크에서 OpenAI가 o-1을 출시하기 전까지는 Anthropic의 Sonnet 등이 여러 사용 사례에서 최고였음
그러나 훌륭한 제품만으로는 부족하고 유통이 동등하거나 더 중요함
Anthropic의 경우 아마존과의 파트너십을 통해 AWS Bedrock에서 모델을 사용할 수 있게 한 유통이 매출의 대부분을 견인하고 있음
4.
API 시장 점유율 경쟁이 매우 근접함
API 부문에서 OpenAI와 Anthropic의 격차가 생각보다 크지 않음
OpenAI의 API 매출은 약 12억15억 달러, Anthropic은 약 8억 달러 수준으로 보임
OpenAI가 API 부문에서 Anthropic보다 약 50100% 정도만 큰 것으로 나타남
이는 주로 Anthropic의 AWS 플랫폼 성공에 기인한 것으로 보임
하지만 OpenAI가 Azure OpenAI 사용에서 더 많은 수요 증가를 보이지 않는 점도 의아함
OpenAI와 Anthropic이 각각 Azure와 AWS API 수익을 어떻게 계산하는지에 차이가 있는지 의문이 제기됨
5.
자본 요구 사항이 계속 커짐
두 회사의 손실과 보도된 투자 유치 규모(OpenAI 65억 달러, Anthropic 10억 달러 초과)를 볼 때 기반 모델에는 계속 많은 자본이 필요할 것이 분명함
경쟁할 수 있는 플레이어 수도 매우 적음. 기본적으로 OpenAI, Anthropic, Meta, Mistral, Google, X.AI 및 Amazon/Microsoft의 다양한 시도 정도만 존재함
이들 회사가 언젠가는 수익성을 추구해야 하므로(당장은 아니더라도 자본이 여전히 사용 가능하기 때문) 다음과 같은 추세에 베팅하는 것으로 보임:
시간이 지남에 따라 유추 비용이 크게 줄어들어 구독 제품/API의 마진 개선
모델 성능이 향상됨에 따라 소비자 구독 요금 인상 가능성. OpenAI는 이미 올해 월 22달러, 향후 몇 년 동안 월 44달러까지 가격을 인상할 것임을 시사함
o1에서 강조된 바와 같이, 1~2년마다 급증하는 교육 비용을 다소 늦추기 위해 교육 시점 컴퓨팅에서 추론 시점 컴퓨팅으로 전환
Reaction
Comment
Share
L
Lighthouse

OpenAI 데브데이 주요 발표사항 요약

ChatGPT의 고급 음성 모드와 유사한 기능을 구현할 수 있게 해주는 Realtime API
o1 모델의 Rate Limit을 GPT-4o와 같도록 상향(분당 1만회)
자동 프롬프트 캐싱으로 GPT-4o API의 가격 인하. 반복된 호출에 대해서 추가 개발없이 50% 저렴
멀티 모달 파인튜닝 API
작년부터 올해까지 OpenAI 플랫폼에서 활동 중인 앱 수는 3배 증가했으며, 활동 중인 개발자 수는 300만 명에 달함

o1 모델에 대한 개요

OpenAI는 새로운 추론 모델인 o1을 출시하였음
o1은 기존의 GPT-4o와는 다른 새로운 모델 군으로 분류됨
OpenAI는 다양한 사용 사례에 맞는 여러 모델을 개발하는 것이 미래의 방향이 될 것이라고 봄
o1은 체인 사고 형태로 생각할 수 있는 능력이 뛰어나 프로그래밍 작업에 적합하지만 속도가 느리고 비용이 많이 듦
대부분의 프롬프트는 o1의 고급 추론 능력을 필요로 하지 않기 때문에 o1은 기본 모델이 되지는 않을 것임
See more...
Reaction
Comment
Share
L
Lighthouse
개발팀에서 조직의 지식을 수집하고 보존하는 유용한 방법 중 하나는 유용한 스니펫, 스크립트 또는 워크플로우 모음을 늘리는 것

그래서 많은 리포지토리에 Makefile, bash 스크립트 같은 것들이 만들어짐
조직 전반에 걸쳐서 유용한 도구 설치, 상용구 코드 생성, 아무도 기억하지 못하는 복잡한 AWS 명령 실행 같은 것은 어떻게 해야 할까?
Slack이나 Shopify와 같은 일부 회사에는 자체 내부 CLI가 있음
최신 터미널인 Warp에는 워크플로를 문서화하고 공유할 수 있는 기능이 있음
조직 내부용 CLI는 쉽게 만들수 있음. 예로 acme란 회사용 CLI를 제작해 봄
CLI 설계 요구사항
acme <command>로 어디서든 명령어를 실행할 수 있는 공통 진입점을 가짐
모든 개발자는 특정 리포지토리로 먼저 이동할 필요 없이 어디서나 acme <command>를 실행하여 명령을 트리거할 수 있음
개발자들이 새 명령어를 쉽게 기여할 수 있도록 함
acme update로 새 버전을 쉽게 배포할 수 있게 함
크로스 플랫폼 지원(예: acme download something을 하면 Linux에서는 curl, Windows에서는 Invoke-WebRequest 사용)
acme list로 사용 가능한 명령어 목록과 간단한 설명을 볼 수 있게 함

just를 사용해 프로젝트 시작하기
just는 make와 유사하지만 명령어 실행에 특화된 도구임
크로스 플랫폼을 지원하고 플랫폼 특화 명령어도 실행 가능함
다른 옵션으로는 Slack의 magic-cli(Ruby를 잘 안다면 시작하기에 훌륭함)나 make가 있음

프로젝트 세팅하기
just 설치. 여기 지침 따르기
~/acme/cli 폴더 만들고 루트에 다음 justfile 추가:
Reaction
Comment
Share
L
Lighthouse
모든 플로팅 요소를 배치하고 인터랙션을 생성하는 자바스크립트 라이브러리

- Smart Anchor 포지셔닝 : 다른 요소 옆에 고정하고 충돌을 피하여 시야에 유지
 -Placement, Shift, Flip, Size, Arrow, Virtual 등 지원
- React 인터랙션으로 자신만의 플로팅 UI 구축
 -툴팁, 팝오버, 셀렉트 메뉴, 콤보박스, 드롭다운 메뉴, 다이얼로그
-Tree-shakeable & Platform-agnostic
-웹용 공식 바인딩, React DOM, React Native 및 Vue 외에도 <canvas> 도 지원
😝
1 Reaction
Reaction
Comment
Share
L
Lighthouse
라마3.1 공개!

405B 모델도 있네요.
128K 컨텍스트 길이, 8개 언어를 지원하며, 405B 모델을 추가(8B, 70B, 405B)
누구나 파인튜닝, 정제하고 어디에나 배포할 수 있는 오픈소스 인스트럭션-튠드 AI 모델
새로 공개된 405B 모델은 MMLU(일반), Human Eval(코딩), GSM8K(수학) 벤치등에서 GPT-4o와 거의 비슷하거나 나은 수준을 달성
유연성과 제어력에서 최고 수준의 AI 모델
커뮤니티가 합성 데이터 생성 및 모델 증류와 같은 새로운 워크플로우를 활용할 수 있게 해줌
15조 개 이상의 토큰을 사용하여 훈련되었으며, 16000개 이상의 H100 GPU 사용
업그레이드 된 70B 모델은 대부분의 벤치에서 GPT-3.5 Turbo를 훨씬 뛰어넘음
Reaction
Comment
Share
L
Lighthouse
TXTAI
임베딩 DB는 벡터 인덱스(Sparse 및 고밀도), 그래프 네트워크, 관계형 데이터베이스를 결합한 것
→ 이를 통해 SQL, 토픽 모델링, 검색 증강 생성(RAG) 등을 통한 벡터 검색이 가능
→ 독립적으로 사용하거나 대규모 언어 모델(LLM) 프롬프트에 대한 강력한 지식 소스로 사용
txtai 의 기능
→ SQL, 객체 스토리지, 토픽 모델링, 그래프 분석 및 멀티모달 인덱싱을 통한 벡터 검색
→ 텍스트, 문서, 오디오, 이미지 및 비디오용 임베딩 생성
→ LLM 프롬프트, 질문 답변, 라벨링, 전사, 번역, 요약 등을 실행하는 언어 모델 기반의 파이라인
→ 파이프라인을 함께 연결하고 비즈니스 로직을 집계하는 워크플로우
→ txtai 프로세스는 단순한 마이크로서비스 또는 다중 모델 워크플로우일 수 있음
→ Python 또는 YAML로 빌드
→ JavaScript, Java, Rust, Go 용 API 바인딩 제공
→ 로컬로 실행하거나 컨테이너 오케스트레이션으로 스케일아웃
Reaction
Comment
Share
L
Lighthouse
스테이블 디퓨젼으로 만화책 프린팅까지 해버렸다!?

[요약]

StableDiffusion 1.5 + iComix 모델
캐릭터는 프롬프트에서 유명 배우들을 믹싱해서 일관성(Consistency) 유지
옷 일관성은 ControlNet Reference 모델을 적용해서 달성
ControlNet OpenPose and Depth로 원하는 포즈를 생성
포토샵으로 대화 말풍선과 레이아웃 처리
👍🏻
1 Reaction
Reaction
Comment
Share
L
Lighthouse
LLM Application 스택의 "다양한 조합을 쉽게 테스트"하고 "원하는 목표에 빠르게 도달"할 수 있도록 "신속한 실험"을 위한 App 개발 구조를 제공

모델, 프롬프트, 컨텍스트, 비즈니스 로직, 아키텍처 등의 다양한 조합으로 쉽게 교체할 수 있는 모듈식 LLM Application 또는 Workflow를 만들 수 있음
많은 실험을 수행하고 데이터를 사용하여 Application 성능을 객관적으로 평가하여 정확도를 향상
Docker 이미지로 다른 클라우드 제공업체에 배포 가능
REST API 또는 SDK를 통해 LLM Application 또는 Workflow를 다른 서비스와 통합할 수 있음
Palico Studio를 통해 LLM Application을 관리할 수 있음
Reaction
Comment
Share
L
Lighthouse
2020년대 초반, 생성 AI 도구에 대한 관심이 폭발적으로 증가했습니다. 작문, 코딩, 애니메이션, 정보 소비 방식에 대한 논의가 활발히 이루어졌지만, 도구의 형태에 대한 언급은 상대적으로 적었습니다. 이와 같은 배경에서, 데이터베이스 아키텍처의 진화는 주목할 만한 변화를 보여왔습니다.
1960년대 후반, 정보 시스템은 방대한 양의 데이터를 처리하면서 관련 정보를 검색하는 과정이 점점 더 비용이 많이 드는 문제에 직면했습니다. 이에 1980년대와 90년대에는 관계형 데이터베이스가 지배적인 솔루션으로 자리 잡았습니다. 관계형 데이터베이스는 데이터를 구조화된 관계를 가진 테이블 모음으로 표현할 수 있게 해주었고, SQL과 같은 쿼리 언어를 통해 더 빠른 데이터 검색을 가능하게 했습니다. IBM, Oracle, Sun Microsystems, MongoDB 등 특정 기업들이 각 신흥 시장에서 입지를 굳혔으며, 특히 Oracle은 관계형 데이터베이스 세계를 주도했습니다.
그러나 정보 저장 및 액세스 방식은 계속 변화해 왔습니다. 최근에는 비정형 데이터를 처리할 필요성이 커지면서 벡터 데이터베이스가 등장했습니다. 지난 50년 이상 스키마는 주로 구조화된 데이터 관계를 중심으로 구성되었지만, 점점 더 많은 사람들이 데이터 모호성을 처리할 수 있는 도구를 필요로 하게 되었습니다. 벡터 데이터베이스는 GPT와 같은 트랜스포머 기반 대규모 언어 모델(LLM)이 텍스트의 장기 의존성을 포착하는 데 도움을 줍니다. 그러나 이러한 모델의 장문 이해력을 유지하는 것은 계산적으로 비용이 많이 들 수 있습니다.
벡터 데이터베이스는 이러한 모델의 컨텍스트 창을 확장할 수 있지만, 여전히 입력과 출력에 의해 작동되는 멍청한 인프라입니다. 데이터 자체를 이해하거나 해석할 수 있는 능력은 부족하며, 단순히 지시받은 대로 데이터를 저장하고 검색하는 저장소 역할만 할 뿐, 본질적인 지능이나 상황 인식 능력은 없습니다.
2020년 GPT-3의 출시로 AI는 기업 제품의 부록이 아니라 핵심 기술로 점점 더 많이 사용될 수 있게 되었습니다. 트랜스포머 아키텍처, 데이터 양 증가, 성능 향상 등으로 AI 기반 제품 개발의 토대가 마련되었습니다. AI-Native(AI 기반) 기업이 증가하고 규모가 커짐에 따라, AI 기반 사용 사례를 지원하는 도구의 필요성도 높아졌습니다. 첫 번째 물결의 AI 핵심 기업들은 주로 기존 모델을 사용한 추론에 초점을 맞추었지만, 성능이 향상된 모델(특히 쉽게 접근할 수 있는 오픈 소스 모델)로 인해 기업은 AI 기반 비즈니스로서의 역량을 더 깊이 구축할 수 있게 되었습니다.
이러한 확장성은 AI 기반 기술 스택이 어떤 모습일 수 있는지에 대한 기회의 세계를 열어주고 있습니다. AI의 발전과 함께 데이터베이스 기술도 계속 진화하며, AI와 데이터베이스의 융합은 앞으로의 기술 발전에 중요한 역할을 할 것입니다.
Reaction
Comment
Share
L
Lighthouse
Anthropic은 Claude 3.5 Sonnet을 출시했습니다. 이는 곧 출시될 Claude 3.5 모델 가족 중 첫 번째 버전으로, 기존 Claude 3 Opus와 경쟁 모델들보다 뛰어난 성능을 자랑합니다. Claude 3.5 Sonnet은 중급 모델인 Claude 3 Sonnet과 동일한 속도와 비용으로 제공됩니다.
제공 방식
Claude 3.5 Sonnet은 무료로 Claude.ai와 Claude iOS 앱에서 사용할 수 있으며, Claude Pro 및 Team 플랜 구독자는 높은 요청 한도와 함께 액세스할 수 있습니다. 또한, Anthropic API, Amazon Bedrock, Google Cloud의 Vertex AI를 통해서도 사용할 수 있습니다. 비용은 백만 입력 토큰당 $3, 백만 출력 토큰당 $15이며, 200K 토큰의 컨텍스트 윈도우를 제공합니다.
성능 향상
Claude 3.5 Sonnet은 대학원 수준의 추론(GPQA), 학부 수준의 지식(MMLU), 코딩 능력(HumanEval)에서 새로운 기준을 세웠습니다. 유머와 복잡한 지시 사항을 이해하는 능력이 크게 향상되었으며, 자연스럽고 공감가는 톤으로 고품질의 콘텐츠를 작성할 수 있습니다.
내부 평가 결과
내부 코딩 평가에서 Claude 3.5 Sonnet은 문제의 64%를 해결해 Claude 3 Opus의 38%를 능가했습니다. 이 평가는 자연어 설명을 바탕으로 오픈 소스 코드베이스의 버그를 수정하거나 기능을 추가하는 능력을 테스트했습니다. Claude 3.5 Sonnet은 코드 번역을 쉽게 처리하여 레거시 애플리케이션 업데이트와 코드베이스 마이그레이션에 특히 효과적입니다.
시각적 능력
Claude 3.5 Sonnet은 표준 시각적 벤치마크에서 Claude 3 Opus를 능가하며, 시각적 추론을 필요로 하는 작업에서 두드러진 성능을 보입니다. 불완전한 이미지에서 텍스트를 정확하게 전사하는 능력은 소매, 물류, 금융 서비스 분야에서 매우 유용합니다.
Artifacts 기능 도입
오늘 Claude.ai에 도입된 Artifacts는 사용자가 생성한 코드 스니펫, 텍스트 문서, 웹사이트 디자인 등의 콘텐츠를 실시간으로 편집하고 프로젝트와 워크플로에 통합할 수 있는 동적 작업 공간을 제공합니다.
안전 및 프라이버시
Claude 3.5 Sonnet은 ASL-2 수준에서 엄격한 테스트를 거쳤으며, 영국 인공지능 안전 연구소(UK AISI)와 협력하여 사전 배포 안전 평가를 완료했습니다. 사용자 데이터는 명시적인 허가 없이는 학습에 사용되지 않습니다.
향후 계획
Claude 3.5 모델 가족의 완성을 위해 올해 말 Claude 3.5 Haiku와 Claude 3.5 Opus를 출시할 예정입니다. 새로운 기능과 모달리티를 개발하여 기업 애플리케이션 통합을 지원하고, 사용자의 선호도와 상호작용 기록을 기억하는 'Memory' 기능을 탐구하고 있습니다.
우리는 항상 Claude를 개선하고 사용자 피드백을 반영하여 더 나은 경험을 제공하기 위해 노력하고 있습니다. Claude 3.5 Sonnet에 대한 피드백을 제품 내에서 직접 제출하여 개발 로드맵에 반영할 수 있습니다.
Reaction
Comment
Share
L
Lighthouse
애플 인텔리전스가 공개된 후 디 에딧에서 분석한 글을 퍼왔습니다 :)
“애플 인텔리전스의 목표는 인간을 대체하는 것이 아닙니다. 더 나은 일상을 가질수 있도록 돕는 것을 중심에 두고 있습니다. 이를 위해서 모든 기기 경험에 직관적으로 통합되는 것을 목표로 했습니다. 모든 인텔리전스는 개인적인 맥락을 짚어내야 합니다. 이를 위해서는 광범위한 개인적인 정보가 필요했고, 여기엔 커다란 책임이 뒤따릅니다.”
👍🏻
1 Reaction
Reaction
Comment
Share
L
Lighthouse
LLM 기술의 금융 시장 활용 (thegradient.pub)
자연어 처리 분야에서 최근 눈부신 발전을 이룬 대규모 언어 모델(LLM)이 금융 시장에서도 활용될 수 있는지에 대한 관심이 높아짐

LLM은 단어나 단어의 일부를 나타내는 토큰의 시퀀스를 모델링하는 데 뛰어난 성능을 보이며, 이를 통해 번역, 질의응답, 사람과 유사한 문장 생성 등의 작업을 수행할 수 있음

금융 시장에서의 LLM 활용 가능성
퀀트 트레이더들은 LLM을 활용하여 가격이나 거래를 예측할 수 있는지에 대해 관심을 가지고 있음
이는 단어 시퀀스 대신 가격이나 거래 시퀀스를 모델링하는 것을 의미함
이러한 접근은 생성 AI와 금융 시계열 모델링에 대해 많은 것을 알려줄 수 있음
LLM과 금융 시장 데이터의 차이점
LLM은 자기회귀 학습자로, 이전 토큰이나 시퀀스의 요소를 사용하여 다음 요소나 토큰을 예측함
그러나 금융 시장 데이터에서는 훈련에 사용할 수 있는 데이터의 양과 정보 내용이 제한적임
예를 들어, GPT-3은 5,000억 개의 토큰으로 훈련되었으나, 주식 시장에서는 연간 1,770억 개의 토큰만 사용 가능함
또한, 금융 시장에서의 토큰은 가격이나 수익률, 거래량 등으로, 언어 모델에서의 음절이나 단어보다 예측하기가 훨씬 어려움
금융 시장에는 노이즈가 시그널보다 훨씬 많으며, 시장 참여자들이 비합리적인 거래를 하거나 근본적인 변화와 무관한 이유로 거래할 수 있음

AI 기술의 금융 시장 적용 가능성
다중 모달 학습은 이미지와 텍스트 입력 등 다양한 모달리티의 데이터를 사용하여 통합 모델을 구축하는 것을 목표로 함
금융에서는 기술적 시계열 데이터와 트위터 상의 감성이나 그래픽 상호작용, 자연어 뉴스 기사, 위성 이미지 등 다양한 유형의 비가격 정보를 통합하여 예측하는 데 활용될 수 있음
잔차화(residualization)는 금융과 AI 모두에서 중요한 역할을 하지만, 두 영역에서 서로 다른 역할을 담당함
LLM의 주요 성공 요인 중 하나는 장기 시야에 걸쳐 토큰 간의 유사성이나 강도를 식별할 수 있는 능력임
금융 시장에서는 여러 시간 범위에 걸쳐 시장 변화의 일부 측면을 설명할 수 있는 다중 스케일 현상을 분석하는 데 도움이 될 수 있음

LLM의 금융 시장 활용 방안
LLM을 활용하여 시장에서 관찰되는 특성을 모방하는 모의 주가 궤적을 생성할 수 있음
이는 금융 시장 데이터가 다른 출처에 비해 희소하다는 점을 고려할 때 매우 유용할 수 있음
인공 데이터는 로봇 공학 등에서 성공적으로 적용된 메타 학습 기법의 문을 열어줄 수 있음
금융 시장 실무자들은 종종 거래 전략이 상당한 이익이나 손실을 경험할 가능성이 더 높은 극단적인 사건에 관심을 가짐
극단적인 시나리오에서 샘플링할 수 있는 생성 모델은 유용할 수 있지만, 극단적인 사건은 정의상 드물게 발생하므로 적절한 매개변수를 결정하고 해당 분포에서 데이터를 샘플링하는 것은 어려움

LLM의 투자 분석 활용 가능성
LLM이 정량 거래를 대체할 가능성은 현재로서는 낮아 보이지만, 펀더멘털 분석에는 도움이 될 수 있음
AI 모델이 발전함에 따라 투자 논거를 정교화하고, 경영진 논평의 불일치를 발견하거나, 관련 산업 및 기업 간의 잠재적 관계를 발견하는 데 도움이 될 수 있음
이러한 모델은 모든 투자자에게 찰리 멍거와 같은 역할을 제공할 수 있음
Reaction
Comment
Share
L
Lighthouse
KPMG Lighthouse ASPAC Region 워크샵 @ 쿠알라룸푸르, 말레이시아
KPMG Lighthouse는 글로벌 조직입니다.
인도 Lighthouse의 경우 개발/컨설턴트 함쳐 900명
중국의 경우 개발팀만 120명이 넘구요.
호주 일본팀 또한 각각 70여명의 ML 엔지니어와 개발자들이 글로벌로 코웍합니다.
그 분위기를 일부 전하고자 저희 KR팀도 리더십 미팅에 참석하였습니다.
이 쟁쟁한 글로벌 개발팀중에 라이트하우스 한국팀은 Chairman's Award를 호주팀과 공동수상 했답니다 ^^
Reaction
Comment
Share
L
Lighthouse
머신 러닝이 아니라 머신 안러닝?
머신 언러닝은 원하지 않는 데이터를 훈련된 모델에서 제거하는 것을 의미하며, 모델을 처음부터 재학습할 필요 없이 모델을 편집하려는 관심이 증가하고 있음

예를 들어 개인정보, 오래된 지식, 저작권이 있는 자료, 유해/위험한 콘텐츠, 위험한 기능, 거짓정보 등을 제거하는 것이 해당됨

언러닝의 형태
정확한 언러닝(Exact unlearning)
언러닝된 모델과 재학습된 모델이 분포적으로 동일하도록 요구함
학습 알고리즘에 모듈식 컴포넌트가 있어 학습 예제의 서로 다른 집합에 대응되는 것이 핵심임
차등정보보호(Differential Privacy)를 통한 "언러닝"
모델이 특정 데이터 포인트에 의존하지 않도록 만드는 것임
언러닝된 모델과 재학습된 모델 사이의 분포적 근접성을 요구함
알려진 예제 공간에서의 실증적 언러닝(Empirical unlearning with known example space)
언러닝 데이터가 정확히 알려져 있는 경우에 적용됨
모델 파인튜닝을 통해 언러닝하는 방식임
알려지지 않은 예제 공간에서의 실증적 언러닝(Empirical unlearning with unknown example space)
언러닝 데이터의 범위나 경계가 명확하지 않은 경우에 적용됨
개념, 사실, 지식 등을 언러닝하는 경우가 해당됨
언러닝을 요청하는 것(Just ask for unlearning)
강력한 LLM에 언러닝을 직접적으로 요청하는 방식임
언러닝 평가
언러닝 평가는 매우 어려운 문제임. 특히 지표나 벤치마크의 부족이 심각함
언러닝 평가에서는 다음의 세가지 측면을 중점적으로 봐야함
효율성 : 재학습 대비 알고리즘이 얼마나 빠른지
모델 효용성 : 보존해야할 데이터나 직교 태스크에서의 성능 저하 여부
망각 품질 : 망각해야할 데이터가 실제로 얼마나 언러닝되었는지
TOFU와 WMDP 벤치마크가 최근 제안되어 언러닝 평가에 도움이 되고 있음
TOFU는 저자 개인정보 언러닝에 초점을 맞추고, WMDP는 바이오/사이버 보안 관련 위험한 지식 언러닝에 초점을 맞춤
인스턴스 기반이 아닌 지식 보유와 이해도에 기반한 높은 수준의 평가를 하고 있음
개인식별정보, 저작권, 유해성, 백도어 등 애플리케이션 중심의 언러닝 벤치마크가 필요해 보임
Reaction
Comment
Share
L
Lighthouse
[원문요약]
LLM의 한계와 가능성에 대한 탐구

LLM의 한계 이해
최근 몇 년간 LLM(Large Language Models)은 다양한 복잡한 문제를 해결해왔음에도 불구하고, 간단해 보이는 문제에서 실패하는 경우가 자주 있습니다. 예를 들어, 경제학, 양자역학 등 복잡한 주제에 대해 응답할 수 있지만, 스도쿠와 같은 간단한 논리 퍼즐을 해결하지 못합니다. 이러한 모델들은 '목표 이탈(goal drift)'과 같은 문제로 인해 주어진 프롬프트의 맥락을 넘어서 일반화하는 데 한계를 보이며, 이는 종종 'Reversal Curse'로 불리는 현상으로, 예를 들어 "A는 B다"로 학습하면 "B는 A다"로 일반화하지 못하는 문제입니다.
실험적 접근
실험을 통해 LLM의 한계를 더 깊이 이해하려는 시도도 이루어지고 있습니다. 예를 들어, Cellular Automata의 예측 실패는 LLM이 학습 데이터에서 명시적으로 제공하지 않는, 반복적이고 동적인 계산을 수행하는 데 어려움을 겪는 것을 보여줍니다. 이러한 실패는 LLM이 단순한 패턴 인식 이상의 작업을 수행하기 위해선 더 복잡한 데이터 처리와 메모리 관리 기능이 필요함을 시사합니다.
LLM의 학습 능력
LLM은 매우 복잡한 데이터 패턴을 학습할 수 있는 능력을 가지고 있으며, 이를 통해 사람들이 생각하지 못한 연결고리나 해답을 제시할 수 있습니다. 그러나 이는 LLM이 실제로 이해하고 있는 것이 아니라, 거대한 데이터셋에서의 숨겨진 패턴을 찾아내는 능력에 기반합니다. 이는 AGI(Artificial General Intelligence)로의 발전에 있어 아직 넘어야 할 큰 장벽을 나타냅니다.
더 많은 에이전트의 필요성
실제 세계의 문제를 해결하기 위해서는 단일 LLM이 아니라 여러 LLM을 연결한 에이전트 시스템이 더 효과적일 수 있습니다. 이러한 에이전트들은 복잡한 문제를 분할하여 해결하고, 각각의 작업에 맞는 전문 지식을 개발할 수 있습니다. 이는 특히 복잡한 작업을 효과적으로 수행할 수 있는 방법으로 제시됩니다.
결론
LLM은 현재로서는 많은 한계를 가지고 있지만, 이를 이해하고 개선하기 위한 연구가 지속적으로 진행되고 있습니다. LLM의 한계를 넘어서기 위해선 기존의 아키텍처를 개선하고, 더 나은 훈련 방법과 데이터 처리 기능을 개발해야 할 것입니다. 그럼에도 불구하고 LLM이 이미 보여준 성과는 인공지능 기술의 놀라운 가능성을 엿보게 합니다.
출처:
Reaction
Comment
Share
L
Lighthouse
알리바바는 Qwen1.5 시리즈 중 첫 100B+ 모델인 Qwen1.5-110B를 선보였으며, 이 모델은 기본 모델 평가에서 Meta-Llama3-70B와 맞먹는 성능을 보이고 있습니다. 또한 MT-Bench와 AlpacaEval 2.0을 통한 채팅 평가에서 우수한 결과를 나타냈습니다.

Qwen1.5-110B 모델은 기존 Qwen1.5 시리즈와 유사하게 동일한 Transformer 디코더 구조로 구성되어 있으며, 그룹화된 쿼리 어텐션(GQA) 기능을 통해 모델 서빙이 효율적입니다. 이 다국어 모델은 32K 토큰의 컨텍스트 길이를 지원하며 여러 언어를 지원합니다.

언어 모델 평가에서는 Qwen1.5-110B가 최신 SOTA 언어 모델인 Meta-Llama3-70B 및 Mixtral-8x22B와 비교되었습니다. 결과적으로 110B 모델은 기본 능력에서 Llama-3-70B 모델과 경쟁력을 보여주었으며, 이는 주로 모델의 크기 확장에 기인한 것으로 보입니다.
채팅 모델 평가에서는 이전 72B 모델과 비교하여 110B 모델이 MT-Bench와 AlpacaEval 2.0에서 탁월한 성능을 보였습니다. 이러한 일관된 개선은 기본 언어 모델의 크기와 성능 강화가 더 나은 채팅 모델로 이어질 수 있음을 시사합니다.
Qwen1.5-110B 개발에 관심이 있는 이들은 Transformers, vLLM, llama.cpp, Ollama, LMStudio, SkyPilot, Axolotl, LLaMA-Factory 등과의 호환성을 파악하기 위 Qwen1.5 블로그를 참조하는 것이 좋습니다.
결론적으로, Qwen1.5-110B는 시리즈 중 가장 큰 모델이자 첫 1000억 개 이상 매개변수 모델로, 최신 SOTA 모델인 Llama-3-70B와 경쟁할 만큼 뛰어난 성능을 보여줍니다. 이는 모델 크기를 확장하는 것이 여전히 성능 향상에 큰 가능성을 가지고 있음을 보여줍니다. 데이터와 모델 크기를 모두 확장하는 방식으로 미래의 개발이 더욱 효과적일 것으로 기대됩니다.
😍
1 Reaction
Reaction
Comment
Share
L
Lighthouse
TED 2064 - 40년후 TED는 어떤 모습일까요?
아티스트 Paul Trillo와 협력해서 OpenAI의 Text-To-Video 모델인 SORA로 생성한 1:30초짜리 동영상을 공유합니다.

TED 로고 빼고는 모든 내용은 Sora로 생성했다고합니다.
그 과정은 대략
약 330개의 클립을 생성한 뒤에 25개를 골라내서 편집했다고 하네요 !
👍🏻
1 Reaction
Reaction
Comment
Share
L
Lighthouse
OpenAI가 아시아 최초의 지사로 일본을 선택하고 OpenAI Japan을 설립
- 일본어에 최적화된 GPT-4 커스텀 모델의 얼리 억세스를 로컬 회사들에게 제공 시작
- 이 모델은 일본어 텍스트 번역 및 요약에서 향상된 성능을 제공하고 비용 효율적이며 GPT-4 Turbo 보다 최대 3배 빠르게 동작
한국은 언제쯤 생길까요 ㅎㅎ
Reaction
Comment
Share
L
Lighthouse
Llama 3의 가장 큰 버전은 올 여름 출시 예정이며, 작은 두 모델은 다음 주에 출시될 예정임

작은 모델의 출시는 Llama 3에 대한 기대감을 불러일으킬 것
Llama 3는 OpenAI의 GPT-4와 같이 이미지 기반 질문 답변 기능을 갖출 것으로 기대됨
가장 큰 버전은 텍스트와 이미지 모두를 이해하고 생성할 수 있는 멀티모달 모델이 될 것임
반면, 다음 주에 출시될 두 개의 작은 모델은 멀티모달이 아닐 것임
Reaction
Comment
Share
L
Lighthouse
OpenAI Assistants 출시 이후 GPT에 지식 기반을 넣어 업무 컨텍스트가 있는 커스텀 AI를 만드는게 너무나 쉬워짐
iPaaS(integration Platform as a Service)를 활용해서 생성형 AI를 Slack, Teams, HubSpot 같은 업무 도구에 붙일 수 있음
Assistants + iPaaS로 코딩 없이 하루 안에 업무 생산성을 높일 수 있음
주요 유스케이스
- 운영 & 인사: 사내 Q&A 봇, 계약서 검토, 이력서 리뷰
- 제품 & 개발: SQL 쿼리 생성, 온콜 보조
- 고객지원: 이메일 초안 작성, 고객 문의 내용 조사 가이드, 고객 감정 분석
- 영업: 리드 고객 조사, 세일즈 카피 작성
= 마케팅: 아티클 작성
Reaction
Comment
Share
L
Lighthouse
최근 Suno.ai를 사용해 MIT 라이선스 하에 제작된 AI 음악 작품이 공개되었습니다. 이 작품은 재즈를 전공한 여성 싱어송라이터가 연주하는 슬픈 피아노 발라드로, AI가 인간과 유사한 음악 작곡을 할 수 있는 다양성과 기술 발전을 보여줍니다. 더 자세한 내용은 여기에서 확인할 수 있습니다.
👍🏻
1 Reaction
Reaction
Comment
Share
L
Lighthouse
[오픈AI의 소라에 대한 상세 내용]
Sora(소라)는 Diffusion Transformers(DiT), Latent Diffusion을 기반으로 하며, 모델과 훈련 데이터셋을 대규모로 확장
소라는 비디오 모델을 확장하는 것이 가치가 있으며, 대규모 언어 모델(LLM)과 유사한 추가 확장이 모델을 빠르게 개선하는 주요 동력이 될 것임을 보여줌
Runway, Genmo, Pika와 같은 회사들이 Sora와 같은 비디오 생성 모델을 위한 직관적인 인터페이스와 워크플로우를 구축 중임
소라 훈련에는 1개월 동안 4,200~10,500개의 Nvidia H100 GPU로 추정되는 엄청난 양의 컴퓨팅 파워가 필요
추론의 경우, Sora는 Nvidia H100 GPU당 시간당 최대 약 5분 분량의 동영상을 생성할 수 있는 것으로 추정. LLM과 비교했을 때, 소라와 같은 확산 기반 모델의 추론은 몇 배나 더 비쌈
소라와 같은 모델이 널리 배포됨에 따라 추론 컴퓨팅이 훈련 컴퓨팅을 지배할 것이며, '손익분기점'은 1,530만~3,810만 분의 동영상이 생성될 때로 추정되며, 그 이후에는 원래 학습보다 추론에 더 많은 컴퓨팅이 소요. 이에 비해 하루에 업로드되는 동영상은 1,700만 분(TikTok)과 4,300만 분(YouTube)
TikTok과 YouTube에서 AI가 생성하는 비디오의 비중을 고려할 때, 추론을 위한 Nvidia H100 GPU의 최대 수요는 약 72만개로 추정됨
Reaction
Comment
Share
L
Lighthouse
Apple에서 MM1이라는 멀티모달 LLM에 대한 연구 결과를 공개하였습니다. (모델 코드나 가중치는 공개하지 않았고, 앞으로도 안 할 것 같습니다)
Image Encoder와 VL-Connector, 그리고 데이터셋과 학습 방법 등에서 모델을 직접 학습하시거나 튜닝하시는 분들께서는 한 번쯤 살펴보셔도 좋을 것 같아 ChatGPT와 함께 정리한 내용을 공유합니다.
[원문 링크]
Apple, 멀티모달 LLM 'MM1'에 대한 연구 결과 발표 (모델 공개X)
PyTorchKR​🔥🇰🇷 🤔💬 이번 주에만 두번째로 Apple의 소식을 전하게 되었습니다. 😲 Apple에서 이번에 VLM 및 시각 연역 추론에 대한 연구를 공개한데 이어, 효율적인 대규모 멀티모달 모델을 구축하는데 있어서의 연구 내용을 공개했습니다. 이 논문은 MM1이라 불리는 Apple의 M-LLM (Multimodal LLM)들을 연구하면서 나온 성과이며, 모델 코드나 가중치 등은 공개하지 않았지만 앞으로 Apple🍎의 행보가 기대되는 논문입니다. 아래 내용을 비롯하여 Multimodal LLM을 학습하시거나 튜닝하실 때 도움이 될만한 내용들이 많으니, 함께 살펴보시죠! Image Encoder Lesson: 이미지 해상도가 가장 큰 영향을 미치며, 모델 크기와 학습 데이터 구성이 그 뒤를 따릅니다. (Image resolution has the highest impact, ...
discuss.pytorch.kr
Reaction
Comment
Share
Share
L
Lighthouse
👍
    L
    Lighthouse
    1.
    구글의 접근 방식
    구글은 개발자 생산성 측정의 모범 사례로 자주 언급되지만, 구글만큼의 투자를 모방하는 것은 대부분의 회사에게는 불가능하다는 주장도 있음
    구글의 Developer Intelligence 팀은 개발자 생산성을 측정하고 리더들에게 통찰력을 제공하는 전문 부서임
    구글은 단일 지표가 생산성을 포착하지 못한다고 믿으며, 속도, 용이성, 품질의 세 가지 차원을 통해 생산성을 바라봄
    Speed 속도: 코드 검토가 완료되는 데 얼마나 걸리나요?
    Ease 용이성: 개발자가 코드 리뷰 프로세스를 진행하는 것이 얼마나 쉽거나 어려운가요?
    Quality 품질: 코드 리뷰를 통해 받은 피드백의 품질은 어느 정도인가요?
    구글은 질적 및 양적 측정을 혼합하여 지표를 계산함
    2.
    링크드인
    링크드인은 마이크로소프트 내에서 독립적으로 운영되며 10,000명 이상의 직원을 고용함
    링크드인에는 개발자 생산성과 만족도를 측정하고 나머지 조직에 통찰력을 전달하는 Developer Insights 팀이 있음
    링크드인은 분기별 설문조사, 실시간 피드백 시스템, 시스템 기반 지표를 사용하여 지표를 캡처함
    분기별 설문조사:
    개발자 인사이트 팀은 분기별 설문조사를 통해 다양한 도구, 프로세스 및 활동 전반의 개발자 경험을 평가
    설문조사에는 약 30개의 질문이 포함되어 있으며 개발자는 약 10분 이내에 답변 가능
    설문조사는 개발자 인사이트 팀이 개발하고 관리하는 독점 플랫폼을 통해 제공되며, 실시간 피드백 및 지표 시스템에서 수집한 데이터를 기반으로 설문조사 문항을 고급 사용자 지정 및 개인화할 수 있음
    실시간 피드백 시스템:
    분기별 설문조사 사이에 피드백을 수집하기 위해 LinkedIn은 개발자가 개발 도구 내에서 수행하는 이벤트와 작업을 추적하고 특정 트리거에 따라 대상 설문조사를 전송하는 실시간 피드백 시스템을 개발
    이 시스템은 스마트 스로틀링 메커니즘을 사용하여 개발자에게 피드백 요청이 과도하게 몰리지 않도록 함
    시스템 기반 지표:
    LinkedIn은 또한 시스템 데이터를 사용하여 지표를 계산하여 빌드 시간 및 배포 빈도와 같은 항목에 대한 고정밀 측정치를 제공
    개발자 인사이트 팀은 이 데이터를 수집하고 분석하기 위한 글로벌 시스템을 유지 관리하며, 이를 개발자 인사이트 허브(또는 iHub)라고 부름
    이 시스템을 통해 LinkedIn의 모든 팀은 각자의 필요에 맞는 사용자 지정 대시보드와 메트릭을 만들 수 있음
    링크드인은 질적 및 양적 지표를 모두 고려
    개발자 순 사용자 만족도(Developer Net User Satisfaction, NSAT) :개발자가 LinkedIn의 개발 시스템에 대해 전반적으로 얼마나 만족하는지를 측정. 분기별로 측정함
    개발자 빌드 시간(Developer Build Time, P50 및 P90): 개발자가 개발 중에 빌드가 로컬에서 완료되기를 기다리는 데 소요되는 시간을 초 단위로 측정
    코드 검토자 응답 시간(Code Reviewer Response Time, P50 및 P90): 코드 검토자가 작성자의 각 코드 검토 업데이트에 응답하는 데 걸리는 시간(업무 시간 기준)을 측정
    커밋 후 CI 속도(Post-Commit CI Speed, P50 및 P90): 각 커밋이 지속적 통합(CI) 파이프라인을 통과하는 데 걸리는 시간을 분 단위로 측정
    CI 결정성(CI Determinism): 테스트 결함의 반대 개념. 테스트 스위트의 결과가 오류가 아닌 유효한 결과일 가능성을 의미
    배포 성공률(Deployment Success Rate): 프로덕션 환경으로의 배포가 얼마나 자주 성공하는지를 측정
    윈화 된 평균(Winsorized Means): 이상값 메트릭 내에서 개선 사항을 인식하는 방법. 최고값과 최저값을 가운데에 가까운 숫자로 대체하여 계산
    개발자 경험 지수(The Developer Experience Index): LinkedIn에서 팀에 제공하는 특별한 지표. 이 지수는 앞서 나열한 지표와 같은 여러 가지 지표를 기반으로 한 종합 점수
    3.
    펠로톤
    펠로톤은 약 3,000-4,000명의 직원을 고용하는 큰 회사로, 링크드인보다 훨씬 작음
    펠로톤의 측정 접근 방식은 개발자 경험 설문조사를 통해 질적 통찰력을 얻기 시작했으며, 나중에는 정량적 지표와 함께 사용함.
    펠로톤은 참여도, 속도, 품질, 안정성의 네 가지 주요 영역에 초점을 맞추어 생산성을 측정함
    참여도(Engagement): 개발자 만족도 점수
    속도(Velocity): 모든 신입사원의 첫 번째 및 10번째 PR까지의 시간, 리드 타임, 배포 빈도
    품질(Quality): 250라인 미만 PR의 비율, 회선 커버리지, 변경 실패율
    안정성(Stability): 서비스 복구 시간
    지표의 많은 부분을 측정하는 개발자 경험 설문조사는 제품 운영 조직의 일부인 Peloton의 기술 지원 및 개발자 경험 팀이 주도
    기술 지원 및 개발자 경험 팀은 설문조사 결과를 분석하고 조직 전체의 리더와 공유하는 역할도 담당
    4.
    스케일업 및 소규모 회사들
    노션, 포스트맨, 암플리튜드, 굿알엑스, 인터컴, 래티스와 같은 여러 스케일업 회사들은 100명에서 1,000명의 엔지니어를 고용함
    이들 회사는 "이동 가능한 지표(Moveable Metrics)" 에 초점을 맞춤
    이동 가능한 지표는 개발자 생산성 팀이 업무에 긍정적 또는 부정적으로 영향을 미침으로써 "이동"시킬 수 있는 지표를 말함. 개발자 생산성 팀이 자신의 영향력을 보여주는 데 유용
    공통 지표들
    딜리버리 용이성 (Ease of Delivery, moveable):
    대부분의 회사는 개발자가 작업을 수행하는 것이 얼마나 쉬운지 또는 어렵다고 느끼는지에 대한 정성적 척도인 제공 용이성을 측정
    여러 DevProd 리더는 팀의 목표가 개발자의 삶을 더 편하게 만드는 것이기 때문에 이 지표를 업무의 '북극성'으로 삼는다고 말함
    이 지표는 상당히 움직일 수 있기 때문에 영향력을 보여주는 데도 유용
    이론적 관점에서 볼 때 이 지표는 인지 부하 및 피드백 루프와 같은 개발자 경험의 주요 측면도 포착
    참여도 (Engagement)
    개발자가 업무에 대해 얼마나 흥미를 느끼고 자극을 받는지를 측정하는 참여도를 추적
    일반적으로 HR 참여도 설문조사에서 참여도를 측정하지만, DevProd 팀도 이러한 이유로 참여도에 집중하는 것을 꼽음
    개발자 참여도와 생산성은 밀접한 관련이 있음. 즉, "행복한 개발자가 생산적인 개발자"라는 말이 있듯이 개발자 참여도는 생산성의 지표로 볼 수 있음
    참여도 측정의 진정한 이점은 속도를 강조하는 다른 지표와 균형을 맞출 수 있다는 것. 소프트웨어를 더 빨리 제공하는 것은 좋지만, 개발자의 행복이 감소하는 것을 희생해서는 안 됨
    시간 손실 (Time Loss, moveable)
    GoodRx와 Postman은 평균 시간 손실량에 주목함
    이는 작업 환경의 장애물로 인해 손실된 개발자의 시간 비율로 측정됨
    이 지표는 개발팀의 업무에 직접적인 영향을 미칠 수 있는 이동 가능한 지표를 제공한다는 점에서 딜리버리 용이성과 유사
    비용으로 환산할 수 있다는 점에서 큰 이점이 있고, 따라서 비즈니스 리더가 시간 손실을 쉽게 이해할 수 있음
    예를 들어 엔지니어링 인건비가 1,000만 달러인 조직에서 이니셔티브를 통해 시간 손실을 20%에서 10%로 줄인다면 이는 100만 달러의 비용 절감으로 이어짐
    변경 실패율 (Change Failure Rate)
    이는 DORA(DevOps Research and Assessment) 연구 프로그램의 네 가지 주요 지표 중 하나
    Amplitude와 Lattice를 비롯한 여러 회사에서 추적하는 최상위 지표
    DORA 팀은 변경 실패율을 다음과 같이 정의:
    "프로덕션 또는 사용자에 대한 릴리스 변경으로 인해 서비스 저하(예: 서비스 장애 또는 서비스 중단)가 발생하고 이후 수정이 필요한 경우(예: 핫픽스, 롤백, 수정 전진, 패치 필요)의 비율"
    5.
    흥미로운 발견들
    DORA 및 SPACE 지표는 선택적으로 사용되며, 모든 회사가 질적 및 양적 측정을 모두 사용함
    DORA : DevOps Research and Assessment
    SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
    "집중 시간" 에 대한 큰 강조가 있으며, 스트라이프와 우버는 "충분한 집중 시간을 가진 일수"와 "엔지니어당 주간 집중 시간"과 같은 구체적인 지표를 공유함
    독특한 지표들
    Adoption Rate (DoorDash, GoodRx, Spotify)
    Design Docs Generated per Engineer (Uber)
    Experiment Velocity (Etsy)
    Developer CSAT/NSAT (Chime, LinkedIn)
    6.
    자신만의 지표를 선택하는 방법
    구글의 Goals, Signals, Metrics (GSM) 프레임워크를 사용하여 지표 선택을 안내하는 것이 좋음
    문제를 해결하고자 하는 목표를 먼저 정의하고, 그 목표를 달성했다는 것을 알려주는 신호를 찾은 다음, 적절한 지표를 선택함
    목표 정의
    Google: "개발자가 빠르고 쉽게 훌륭한 제품을 제공할 수 있도록 지원합니다."
    Slack: "모든 엔지니어에게 원활한 개발 환경을 제공합니다."
    Stripe: "소프트웨어 엔지니어링을 더 쉽게 만듭니다."
    목표로 부터 거꾸로 작업해서 최상위 지표를 정의하기
    개발자가 소프트웨어를 딜리버리하는 것이 얼마나 쉬운가?(Ease) : Ease of Delivery, Deployment Lead Time, Build Failure Rate
    개발자가 소프트웨어를 얼마나 빨리 딜리버리하는지 (Speed) : Perceived Delivery Speed, Perceived Productivity
    제공되는 소프트웨어의 품질 (Quality) : Incident frequency, Perceived Software Quality
    당신이 CTO, VPE, 엔지니어링 리드라면
    가장 좋은 조언은 "문제를 재구성 하는 것(reframe the problem)"
    세가지 버킷에서 지표를 선택할 것
    비즈니스 임팩트
    지금 구축해야 하는 이유는 무엇인가요?
    이 프로젝트가 비즈니스에 어떤 방식으로 수익을 창출하거나 목표를 지원하는가?
    이 프로젝트가 순조롭게 진행되고 있나요, 아니면 지연되고 있나요?
    시스템 퍼포먼스
    엔지니어링 시스템은 빠르고 안정적인가요?
    인프라가 안전하고 잘 유지되고 있나요?
    사용자가 사용하는 서비스에 만족하고 있나요?
    엔지니어링 효율성
    정성적 지표와 정량적 지표를 혼합하여 측정하는 것은 모든 회사에서 공통적으로 나타나는 현상
    각 기업이 사용하는 다양한 측정 항목에서 영감을 얻을 것
    각 기업의 우선순위와 엔지니어링 문화에 따라 중점적으로 측정하는 항목에는 큰 차이가 있음