https://appleinsider.com/articles/23/07/06/apple-is-inventing-a-revolutionary-car-audio-system-for-apple-car

애플이 차량내 오디오에 대한 5개의 새로운 특허를 신청
애플은 "Enclosed Environment" 라는 단어를 차에 대한 완곡표현으로 사용하기로 한듯
특허는 이 단어를 이용하면서 빌딩에도 적용 가능하다고 했지만 차량에도 가능
헤드레스트에 있는 스피커가, 운전자가 회전시에 고개를 돌리거나, 맥도날드 주문을 위해 창문쪽으로 내밀었을때에도 위치를 추적
자동차의 문에 붙어 있는 "Access-Feature-Mounted External Speaker" 관련 특허도 있음. 문이 열리거나 닫혔을때 어떻게 반응할지도 고민하는듯
Vision Pro 에서 얘기하는 Spatial Audio 도 적용하여, 한명이 아닌 여러명을 위한 Group Spatial Audio

https://news.hada.io/topic?id=9722

Threadds Android App (72.3MB)
유니버설 APK. Redex 사용
디버그 코드 포함되어 있음
일부는 React Native로 되어 있음 (Hermes)
UI는 Jetpack Compose를 많이 사용
인스타그램 앱과 많은 부분을 공유
Threads iOS App (244.2MB)
페이스북앱과 달리 동적 라이브러리가 전혀없음
굉장히 큰 플러그인이 있음. BarcelonaShareExtension이 81MB ( InstagramNotificationExtension 이 23.5MB, InstagramShareExtension이 5.6MB 인데 비해)
인스타그램의 FBSharedFramework 가 BarcelonaShareExtension 이랑 많은 부분을 공유
시작 시간 살펴보기
Sign-in 이 네이티브가 아니고 WebView(WKWebView)를 사용하고 있어서 느린것 같아 보임. 아님 백그라운드에서 뭔가 트래킹하거나
개발시간을 단축하기 위해 iOS/Android 모두 인스타그램 앱과 많은 부분을 공유한 것으로 보임. 그게 바뀌는것을 보는 것도 재미날듯

https://news.hada.io/topic?id=9723

왜 개발자를 AI로 대체하는게 어려운지에 대하여
많은 뉴스에서 AI가 개발자를 대체하게 될 거라고 얘기하지만, 소프트웨어 구축에 있어서 가장 어려운 부분은 코딩이 아니라 명확하고 정확한 요구사항을 만드는 것
"그거 버그 아니고 피쳐에요. 어, 잠시만 버그네요"
명확하지 않은 요구사항은 버그를 만들어냄
"AI가 개발자를 대체하려면, 클라이언트는 자신들이 원하는 것을 정확하게 설명해야함. 우린 안전해요"
AI의 현실: 체스 vs. 자율주행 자동차
AI는 체스와 같이 규칙이 한정되고 명확한 영역에서 성공적으로 활용되었음, 하지만 자율주행 자동차는 무한한 변수와 예외 상황으로 인해 AI에게 훨씬 더 복잡한 도전
기술분야에서는 9 다섯개 또는 6개의 Availability(가용성)가 표준임 (99.999% 에서 99.9999%)
99%에 도달하는 비용은 별로 들지 않음. 99%는 당신의 웹사이트가 1년에 3일 이하로 다운된다는 것을 의미함(87.6시간)
하지만 9가 하나 붙을때 마다 거기에 도달하는 비용은 기하급수적으로 증가함
99.9999%가 되려면 1년에 31.5초만 다운되어야 함(99.9%는 526분/8.76시간, 99.99%는 52분, 99.999%는 5.2분)
이를 위해서는 엄청난 계획가 노력이 들어가고, 물론 비쌈
AI가 아무리 좋아진다 한들, 항상 사고의 위험성이 있음
어느 정도의 사고를 허용할지 모르겠는데, 적어도 사람만큼은 되어야함
AI는 소프트웨어를 만들 수 없고, 코드만 만들 수 있음
소프트웨어를 만들고 유지하는 것은 체스보다 운전과 더 공통점이 많음
수많은 변수들이 있고, 규칙은 판단에 의해 결정됨
소프트웨어를 만들 때 원하는 결과가 있겠지만, 그게 체스처럼 단순하지 않음
소프트웨어는 완료 라는 게 거의 없음. 계속 기능이 추가되고 버그가 수정되는 지속적인 Exercise임
소프트웨어와 달리 체스 게임은 일단 이기거나 지면 끝임
소프트웨어 개발에서 우리는 소프트웨어 디자인을 체스의 규칙 엔진처럼 만드는 도구를 가지고 있음: 기술 스펙
최상의 상태에서 이 기술 스펙은 사용자 행동과 프로그램의 흐름을 예측함
하지만, 이런 경우는 거의 없음. 우리는 너무 자주 Wishlist를 기능 스펙으로 받거나, 냅킨에 적은 와이어프레임이나 불분명한 요구사항 문서를 건내 받아서 우리가 최고의 판단을 내리게 만듦
설상가상으로 요구사항들은 변하고 무시되기도 함
불가능한 요구사항들. 원글에선 WIFI 없는데서 문자로 COVID 설문조사를 하는 프로젝트 사례를 얘기함. 안하는게 맞았음
AI가 과연 어런 대응이 가능할까 ?
AI가 기능적인 소프트웨어를 만드는게 가능하려면, 원하는 것을 제대로 알고 이를 명확하고 정확하게 정의할 수 있어야 함
지난 10년간 소프트웨어 산업은 워터폴에서 애자일 방식으로 전환했음
워터폴에선 이해관계자가 자신이 원하는 것을 알고 이를 문서화 할수 있다고 생각했지만, 최종 제품이 전달되었을때 매우 실망했기 때문에 실패했음
애자일은 이 프로세스에 대한 해결책임
AI는 우리가 이미 가지고 있는 소프트웨어를 최신 하드웨어어와 새로운 언어로 재작성하는데는 가장 적합할 수 있음
COBOL로 작성된 소프트웨어를 사용하는 곳은 아직 많지만, 그 언어를 배우는 사람은 거의 없으니까
AI가 이미 만들어진 소프트웨어는 사람보다 더 빠르게 만들수 있겠지만, 그것은 누군가가 이미 소프트웨어가 어떻게 만들어져야 할지를 고민했기 때문임
AI는 우리가 죽음의 행군이라고 부르는 폭포수 프로세스를 사용하면 소프트웨어를 꽤 잘 구축할 수 있음
폭포수에서 누가 끔찍할까? 바로 인간임
단지 프로그래머 팀에게 전달한 문서를 작성하는 부분만이 아니라, 그 이전의 모든 것임
AI가 몇가지 놀라운 일을 할 수는 있지만, 당신의 마음을 읽거나 당신이 원하는 것을 말해주지는 않음

https://news.hada.io/topic?id=9726

기술 산업에서는 새로운 도구와 가젯에 집착하는 경향이 있음
그러나 진정한 숙련과 성공은 도구에만 의존하는 대신 기술과 마인드를 개발하는 데서 나옴
전문가들은 도구의 유무와 상관없이 자신의 기술을 연마하고 기본에 집중하는 중요성을 이해함
이소룡 : "나는 1만가지의 발차기를 1번씩 연습한 사람은 두렵지 않고, 하나의 발차기를 1만번 연습한 사람이 두렵다"
프로와 아마추어를 구분하는 것은 기본 원리에 대한 깊은 이해와 의도적이고 일관된 연습을 통해 얻은 전문지식임
새로움에 대한 매력에 저항하고 대신 영원한 원리와 숙련의 추구에 집중하는 것이 중요
인공지능은 이 숙련의 추구를 더욱 중요하게 만들 수 있음
최신 트렌드를 쫓는 대신 진정으로 자신의 기술을 연마하고 중요한 일을 하는지 스스로에게 물어볼 것
유행에 따르는 사람이 되지 말고 어려운 일에 도전하는 것을 받아들이세요

역시 구글의 Med-PaLM 정도 되면 네이처에 실리는군요.

제목: Large language models encode clinical knowledge

요약
대규모 언어 모델(LLM)은 인상적인 기능을 입증해 왔지만 임상 적용에 대한 기준은 높습니다. 모델의 임상 지식을 평가하려는 시도는 일반적으로 제한된 벤치마크에 기반한 자동화된 평가에 의존합니다. 여기에서는 이러한 한계를 해결하기 위해 전문 의학, 연구 및 소비자 질문에 걸친 6개의 기존 의료 질문 답변 데이터세트와 온라인에서 검색된 새로운 의료 질문 데이터세트인 HealthSearchQA를 결합한 벤치마크인 MultiMedQA를 소개합니다. 사실성, 이해도, 추론, 피해 가능성, 편견 등 여러 축에 따라 모델 답변에 대한 인적 평가 프레임워크를 제안합니다. 또한 5,400억 개의 파라미터로 구성된 언어 모델1(PaLM)과 그 명령어 튜닝 변형인 Flan-PaLM2를 MultiMedQA에서 평가합니다. Flan-PaLM은 여러 가지 프롬프트 전략을 조합하여 모든 MultiMedQA 객관식 데이터 세트(MedQA3, MedMCQA4, PubMedQA5 및 대규모 다중 작업 언어 이해(MMLU) 임상 주제 측정6)에 대해 최첨단 정확도를 달성하며, 특히 MedQA(미국 의사 면허 시험 스타일 문제)의 정확도는 67.6%로 이전 기술을 17% 이상 능가합니다. 하지만 사람이 직접 평가하면 몇 가지 부족한 점이 드러납니다. 이 문제를 해결하기 위해 몇 가지 예시를 사용하여 LLM을 새로운 영역에 맞게 조정하는 매개변수 효율적인 접근 방식인 명령어 프롬프트 튜닝을 도입했습니다. 그 결과 Med-PaLM이라는 모델이 고무적인 성과를 보였지만 임상의에 비해서는 여전히 열등합니다. 모델 규모와 지시 프롬프트 튜닝을 통해 이해력, 지식 회상 및 추론 능력이 향상되어 의학에서 LLM의 잠재적 유용성을 시사합니다. 인간 평가는 오늘날 모델의 한계를 드러내며 임상 적용을 위한 안전하고 유용한 LLM을 만드는 데 있어 평가 프레임워크와 방법 개발이 모두 중요하다는 점을 강조합니다.

링크: https://www.nature.com/articles/s41586-023-06291-2

파트타임 공동 창업자란 없어요. 다만 기회를 엿보는 부업 알바생이 있을 뿐이어요.

6개월 후에 합류할 것이라는 말은, 1) 일단 6개월 후에 지켜질지 알 수 없고 2) 초기스타트업에게 있어서는 6개월은 강산이 바뀌는 변화가 큰 기간인데, 그때 우리 회사는 더 이상 그 사람이 필요치 않을 수도 있고, 더 좋은 사람이 이미 낮은 스톡옵션으로 그 포지션을 채울 수도 있어요.

그래서 그때(6개월 후) 관점으로 그 사람을 평가할 때는 이제 더 이상 필요 없을 수도 있어요.

6개월 후에 합류할 것이라고 말 한다면, 선불로 지분을 약속하지 말고, 그때 가서 이미 합류한 다른 직원들과 비교해서 당신의 가치를 평가해서 지분을 정하자고 말해야해요. 그때까지는 본업에서 돈벌며 부업하는 알바생일 뿐이어요.

회사 지분은 모든 걸 걸고 '풀타임'으로 회사에 몰입하는 사람에게, 합류하는 시점에 배당하는 것이 원칙이어요. 아니면 돈을 내는 사람/기관이거나.

#권도균 #스타트업경영 #경영수업 #창업의시작 #돈보다경영 #투자 #데모데이 #프라이머 #엑셀러레이터 #primer #accelerator

실패에 대한 관점

"한 번뿐인 삶에서 완벽함은 '어리석은 망상'이다. (그러니 서툴더라도 인생을) 즐겨라"

- 밀란 쿤데라

1. 세상에 풀어야 할 문제는 많다. 하지만 당신이 스타트업을 한다면, 특히 B2B 스타트업을 한다면 긴급한 고객의 문제를 풀어라. 고객 입장에서 신생 스타트업의 제품을 구입하는 것은 수술 처음하는 아기 의사가 '너 나한테 수술 받을래?'하는 것과 같다. 정말 긴급하고 절박해야 스타트업의 제품을 사서 쓴다.

2. 고객 인터뷰 중에 모든 고객의 소리를 듣지 말고 중요한 Teaching customer를 잘 정의하고 좁혀나가는 게 중요하다. 그를 위한 제품을 만들고 그들을 조직 내에서 슈퍼스타로 만들어줘라.

3. 기업가는 실패를 통해 배우고 성장한다. 하지만 성장하고 성공한다고 실패를 안 겪지 않는다. 여전히 실패는 계속된다.

https://youtu.be/NKFZTuk_ylY

2003년 이후 설립된 미국의 기업 중 매출 10억 달러 이상인 64개 상장 기업.

https://nbt.substack.com/p/the-billion-dollar-revenue-club

In this new Machine Learning era dominated by LLMs, knowledge Distillation is going to be at the forefront of LLMOps. For widespread adoption and further development of generative ML, we first need to make those models more manageable to deploy and fine-tune.

Just to put some numbers on how unmanageable it can be, SOTA models these days have about ~500B parameters and that represents at least ~1TB of GPU memory to operate with specialized infrastructure. That's a minimum of ~$60,000 - $100,000 per year per deployed model just for inference servers. And that doesn't include fine-tuning nor typical elastic load balancing costs for reliability best practices. Not impossible, but somewhat a high barrier to entry for most businesses.

I always felt that knowledge distillation was a silent hero in this era of transformer-type language models. There are tons of distilled BERT-like models on HuggingFace for example. The concept behind distillation is actually pretty simple. Let's assume you have a large pre-trained model. In the context of LLMs, it could be pre-trained with self-supervised learning and fine-tuned in a RLHF fashion for example. Your pre-trained model now becomes the all-knowing teacher for a smaller student model. If we call the teacher model T and the student model S, we want to learn the parameters for S such that

T(x) = y_t ~ y_s = S(x)

For some data x, we want the predictions y_t and y_s by T and S to be as close to each other. To train a student model, we simply pass the training data through the teacher and student and update the student's parameters by minimizing the loss function l(y_t, y_s) and back-propagating its gradient. Typically we use cross-entropy for the loss function. To train the student model, think about typical supervised learning where the training data is the same or similar to the teacher's training data, but the ground truth label for the student model is the output prediction of the teacher model. You can read more about it in this survey: https://arxiv.org/pdf/2006.05525.pdf.

With the advent of prompt engineering, we now understand better how to extract the right piece of knowledge from LLMs. Techniques like Chain-of-Thought (CoT) greatly improved LLMs performance on few-shot learning tasks. The guys at Google just published an article (https://arxiv.org/pdf/2305.02301.pdf) utilizing CoT to improve the distillation process. The idea is to have the student LLM predicting the rationales for the predictions alongside the predictions and minimizing a loss function between the teacher rationale and the student rationale. Basically by forcing the LLM to explain its predictions, they were able to beat all the distillation SOTA. For example, they outperformed a 540B parameters PaLM model with a 770M parameters T5 model after distillation! I think this paper will have a huge impact in the coming year!

----
Find more similar content in my newsletter: https://TheAiEdge.io
Next ML engineering Masterclass starting July 29th: https://MasterClass.TheAiEdge.io
#machinelearning #datascience #artificialintelligence

https://huyenchip.com/list-100/

Interesting to do lists.

https://huyenchip.com/2023/04/11/llm-engineering.html

Building LLM applications for production

Unleashing LLMs in Production: Challenges & Opportunities. Chip Huyen, Amjad Masad & Michele Catasta

https://www.youtube.com/watch?v=ByhMpN2iSbc

GPT-4 Hackathon Code Results

https://docs.google.com/spreadsheets/d/1tmfn8jKb7T1x7PpyO7rD023tH2zc_WDg_OHh0aVXIrw/edit#gid=174517450

Langchain Gen Mo Hackathon

https://docs.google.com/spreadsheets/d/1GqwPo1FpAbe_awmNZW5ZMH69yc5QtEr7ZYw-ckaz_mQ/edit#gid=795016726