기사 일자 : 23-01-04

https://techneedle.com/archives/42660

 

ChatGPT vs 구글 검색, 누가 이길까?

OpenAI가 인공지능 챗봇 ChatGPT를 공개한 지 1달이 지났다. 인간의 피드백을 통한 강화학습 (Reinforcement Learning from Human Feedback, RLHF)으로 훈련된 ChatGPT는 자연스러운 문체와 방대한 규모의 답변 능력

techneedle.com

2022년 11월 30일 발표된  ChatGPT가 핫한 이슈로 떠오르고 있다.

위 기사는 ChatGPT와 구글을 비교하며 각각의 장단점을 분석하고 있다.

 

- ChatGPT가 구글을 이길 수 있는 이유

1. 구글의 광고수익 부정적 영향

구글은 검색기능을 무료로 제공하여 구글에 잔류하는 시간을 늘리면서 광고수익을 창출하기 때문에 ChatGPT는 구글에 수익구조에 부정적 영향을 끼치게 된다.

 

2. 높은 편의성

ChatGPT는 편하다. 구글은 키워드를 검색하고 링크를 타고 들어가 정보를 탐색해야하는 번거로움이 있다. 또한 사용자가 수동적으로 정보의 적절성 여부를 판단해야하는 수고로움이 존재한다. 반면 ChatGPT는 질문에 대한 적절한 답을 해주기에 편의성이 높다고 할 수 있다.

 

3. 유리한 개인화

ChatGPT는 사용자의 과거 질문을 기억하기 때문에 개인화에 유리하다.

 

 

- ChatGPT가 구글을 이길 수 없는 이유

1. 최신성에 불리

ChatGPT는 2021년 이후의 정보에 취약하다. 학습을 위해 오랜시간이 걸리기 때문에 최신성을 유지할 수 있는 방안이 필요하다. 반면 구글은 최신정보를 제공하는데 탁월하다.

 

2. 조작가능성

구글은 정보를 생성하는 주체가 사람인 반면 ChatGPT는 개발하는 조직으로 중앙화되어있기 때문에 조작 가능성에 대한 이슈에 민감할 수 밖에 없다.

 

3. 수익구조

구글은 무료로 사용자에게 검색기능을 제공하고 광고를 통해 수익을 얻는 고객-광고주 공존의 선순환 수익구조를 갖고 있다. 반면 ChatGPT의 수익구조는 아직 검증되지 못한 상황이다.

'AI 스크랩' 카테고리의 다른 글

아마존의 포장재 최적화 알고리즘  (0) 2023.03.01

기사 일자 : 2023-01-30

https://techneedle.com/archives/42708

 

아마존은 과포장 이렇게 해결한다

2022년 현재, 3억 명의 아마존 고객이 190만 판매자들로부터 상품을 구매한다. 전 세계 175개가 넘는 풀필먼트 센터에서 하루 약 160만 개의 배송을 처리한다. 거래되는 상품이 많다 보니 포장재 (골

techneedle.com

 

22년 기준, 아마존은 3억명의 고객과 190만명의 판매자, 175개 이상의 풀필먼트 센터를 보유하고 있는 거대 글로벌 기업이다.

 

아마존의 입장에서는 포장제를 최적화 시키는 것이 작업의 편의, 고객경험의 향상, 에너지 절약 등의 이유로 굉장이 중요한 이슈이다.

이들은 Reducing Amazon’s packaging waste using multimodal deep learning이라는 논문에서 딥러닝을 활용해 포장을 최적하는 방법을 소개했다.

 

첫째로 상품기본 정보와 상품의 긍정적/부정적 후기와 같은 텍스트 정보에 집중했다.

둘째로 풀필먼트 센터로 들어오는 상품의 이미지를 대규모 컴퓨터 비전 기술을 이용해 분석했다.

셋째로 좋은 성능의 머신러닝 모델을 학습하기 위해서 포장애 문제가 있는 상품과 문제가 없는 상품 데이터가 5 : 5 비율로 필요했는데, 포장에 문제가 없는 상품의 비율이 부족했다. 아마존은 Two-phase Learning with Random Under Sampling을 통해 이러한 데이터 불균형을 해결했다.

마지막으로 텍스트, 이미지 등 다양한 데이터를 고려하는 다중 형식 딥러닝 모델을 고안했다. 마치 사람이 직접 눈으로 상품정보와 상품 후기를 확인한 상태에서 실제 상품을 보면서 어떻게 포장해야 할지에 대해 판단하는 모델을 만들게 된 것이다.

'AI 스크랩' 카테고리의 다른 글

ChatGPT vs Google 비교  (0) 2023.03.01

 

1. 경우의 수를 구하는 방법은 모든 의상분류의 의상 수 +1한 값을 곱한 값에 1(알몸 상태)을 뺀값이다.

2. map을 사용하여 item_category의 중복 없이 입력받는다.

3. map["item_category"]++;  와 같이 입력받을 경우 해당 의상분류마다 카운팅이 가능하다.

 

케이스별 답을 출력할때 \n을 해주지 않으면 틀렸습니다가 나온다.

 

#include <iostream>
#include <algorithm>
#include <map>
#include <string>

using namespace std;

int main()
{
    ios::sync_with_stdio(false);
    cin.tie(0);
    cout.tie(0);
    int t;
    cin >> t;

    while(t--){
        map<string, int> m;
        int n;
        int result = 1;

        cin >> n;
        for (int i = 0; i < n; i++){
            string a, b;
            cin >> a >> b;
            m[b]++;
        }

        for (auto i : m){
            result *= (i.second + 1);
        }

        cout << result - 1 << "\n";
    }
}

 

js쓰다가 c++로 넘어오니 ""와 ''의 차이 때문에 컴파일 에러가 많이 났다.

 

'Algorithm' 카테고리의 다른 글

[백준] 11403번 경로 찾기 c++  (0) 2022.12.25
[백준] 14500 테트로미노 c++  (0) 2022.12.24
[백준] 5525번 IOIOI c++  (0) 2022.12.10
[백준] 5430번 AC c++  (0) 2022.12.10
[백준] 10026번 적록색양 c++  (0) 2022.11.30

아래 코드와 같이 컨테이너 안 어느 요소든 탭했을때 textfield의 focus를 null로 만들어 키보드를 내리는 기능을 구현하려고 했다.

 

문제의 코드

 

컨테이너 안 빈공간을 눌러도 키보드가 닫히지 않았다.

 

하지만 신기하게 컨테이더 안에 circle 요소나 text를 클릭하면 기능이 동작을 했다.

그래서 container가 할당되는 공간이 없는 건가 싶어서 color를 넣어 확인했지만 이미 container를 가득 채운 상태였다.

더 이상한 것은 color를 넣으니 원래 의도하던대로 기능이 잘 작동한다는 것이었다.

 

혼란에 빠져 구글링을 하다가 내가 겪은 문제를 다룬 깃헙이슈를 발견했다.

 

[GestureDetector with Container not working without color]

https://github.com/flutter/flutter/issues/32364

 

GestureDetector with Container not working without color · Issue #32364 · flutter/flutter

Hey, I don't know if this is the expected behavior but a GestureDetector with a Container in it's child, the onTap callback is not executed when the Container doesn't have a color. For ...

github.com

 

 

결론은 container의 color를 따로 지정하지 않으면 container의 decoration이 null로 설정되어서 tap을 인식하지 못한다고 한다.

 

해결방법

1. color를 넣어준다.

2. color를 넣지 않아야하는 경우라면 Colors.transparent(투명)를 넣는다.

 onTap이 잘 작동할 것이다.

Link태그와 onclick navigate를 함께 사용할 경우 navigate가 동작하지 않는 현상

 

글을 삭제한 후에  다시 글 목록으로 돌아가는 기능을 구현하려고 했다.

Link 태그의 to와 별개로 onclick의 handler를 두어서 다른 작업을 처리한 후에 navigate하는 기능을 만들었지만 동작하지 않았다. handler에서 분명 navigate 달아줬음에도 페이지가 그대로 멈춰있었다.

 

원인은 다음과 같다.

Link테그는 a테그를 기반으로 한다. Link태그를 클릭했을때 onclick function이전에 a테그의 direction만 적용되고 onclick 안에 선언한 navigate는 실행되지 않았다. 나의 경우 Link태그에 to 자체를 설정하지 않았기 때문에 페이지에 그래도 잔류하게 되었던 것이다.

 

해결방법

이를 해결하기 위해서는 html 자체의 동작을 막아주는 event.preventDefault()를 이용해야 한다. onclick에 들어가는 콜백함 수 안에 event.preventDefault() 선언해줌으로서 Link 태그의 동작을 막을 있다.

event.preventDefault()는 a태그 뿐 아니라 form태그에서 submit을 누르는 경우 새로고되는 등의 현상을 막기위해 사용되기도 한다.

 

 

const deleteHandler = (e) => {
    e.preventDefault();
    dispatch(deleteEvent(event));
    navigate("/event", { replace: true });
};
  
  
<Link onClick={deleteHandler}>삭제하기</Link>

 

사실 그냥 button태그를 쓰면 되는데 실수로 태그를 안바꾸고 구현하다가 처음 겪는 현상을 마주해서 알아보았다.

useSelect에서 가져온 배열중 조건에 객체 하나를 가져온 후애 이를 화면에 뿌리는 작업을 하는 중에 발생현 현상이다.

무한 랜더링 발생

처음에는 원인을 도저히 알 수 없었으나 find를 사용할 경우 잘 동작하는 것을 확인한 후 힌트를 얻었다.

무한랜더링이 발생한다는 것은 filter로 반환받은 객체가 항상 다른 값을 반환하여 useEffect가 계속 불려진다는 것이었다.

그래서 find와 filter의 반환 값 형식의 차이에 대해 알아 보았다.

 

filter: 조건에 맞는 모든 객체의 리스트를 새로 만들어 반환한다.

find: 조건에 맞는 첫 객체를 반환한다.

 

find를 사용할 경우 store에서 항상 같은 객체가 반환 될 것이 때문에 한번 랜더링 된 후 값이 바뀌지 않게 된다.

초기 랜더링 -> useSelect -> useEffect -> 리랜더링 -> useSelect -> 동일한 값을 받으므로 useEffect는 불리지 않음

반면 filter를 사용할 경우 항상 새로운 배열을 만들어 반환하게 되니 무한랜더링이 발생하는 것이였다.

초기 랜더링 -> useSelect -> useEffect -> 리랜더링 -> useSelect -> 새로운 값을 받으므로 useEffect가 다시 불림 -> 리랜더링 반복

 

useselect를 통해 list를 가져와서 화면에 뿌려주는 기능을 구현하는 중에 발생한 현상이다.

useselect는 컴포넌트가 랜더링되고 난 후에 실행된다. 따라서 랜더링 과정에서 실행되는 useState로 선언한 list에는 undefind가 된다.

 

해결방법

useselect는 hook이기에 useEffect 안에서 동작할 수 없다. 그렇기에 useselect의 실행 시점을 고려해서 list state를 업데이트 해준다. useEffect의 디펜던시로 useSelect를 통해 가져온 값을 설정하는 방식으로 해결하였다.

 

다음과 같은 순서로 동작하게 된다.

초기 랜더링 완료(이때 state는 undefind) → useSelect 실행 → store에서 list를 가져온다. → useEffect 의존성 발현 → useEffect안에서 setState실행 → 컴포넌트 리랜더링 → state변경 → 원하는 state값 화면에 출력 순이 된다.

참고로 state가 실제적으로 새로운 값으로 치환되는 시점은 ‘리랜더링이 된 후’ 이다.

const getList = useSelector((state) =>
    state.lists.find((list) => list.id == id)
  );

const [list, setlist] = useState(null);

useEffect(() => {
  setlist(getList);
}, [getList]);

 

참고한 글

https://velog.io/@ahn0min/useSelector-useState-를-같이-사용하며-생긴-문제점

https://medium.com/hcleedev/web-usestate의-동작-원리와-함정-7b4825c16b9

❗ 이중모드

os에는 이중모드가 존재한다. 일반적으로 user mode와 system mode이다. 두 모드의 차이는 무엇일까? 바로 priviledge instruction의 허용여부이다. system mode에서는 priviledge instruction을 허용하지만 user mode에서는 허용되지 않는다.

 

그렇다면 priviledge instruction(특권 명령)이란 무엇일까?

 

priviledge instruction

os에는 stop, timer, interrupt, in, out와 같은 priviledge instruction(특권 명령)이 존재한다. 이러한 명령들을 따로 분류해놓지 않을 경우, 일반 프로세스에서 이를 남용할 가능성이 있다. 원활한 실행을 돕기 위해 특권명령이 존재한다.

 

이중모드의 구현방식

cpu register 안에는 carry, overflow 같은 flag들이 존재한다. 이처럼 이중모드를 구분하는 flag를 둔다. OS가 실행될때만 이중모드의 flag를 1로 하고 나머지의 경우 0으로 두는 등의 방식으로 구현된다.

 

❗ HW보호

Application에서 HW와 관련한 작업들을 시도할 때는 모두 OS를 거처 수행된다. HW를 보호하고 원활한 실행을 도모하기 위해서이다.

 

1. I/O보호(OS)

여러 Process에서 동일한 I/O 자원(disk, printer 등)에 접근을 시도한다면 상당히 혼잡해질 것이다. 작업의 혼선을 방지하고 권한 밖에 일을 하지 못하도록 막기위해 I/O와 관련된 명령들을 priviledge instruction으로 설정한다. 모든 process는 OS를 통해 IO에 접근하게 된다.

 

2. Memory 보호(MMU)

어떤 process가 다른 process 혹은 OS의 메모리 영역에 침범하는 것을 방지한다. CPU와 메모리 사이에서 MMU(memory management unit)을 통해 구현된다. process가 자신의 권한 밖의 영역 접근을 시도하는 경우 MMU에서 CPU에게 interrupt를 발생시킨다.

 

3. CPU보호(Timer)

어떤 process가 고의적을 CPU자원을 독점하는 것을 방지한다. OS에서 Timer를 두어서 일정시간이 지나면 interrupt를 걸어 다른 process에게 CPU자원이 할당되도록 한다.

'Operating system' 카테고리의 다른 글

[운영체제] 인터럽트 기반 운영체제  (0) 2022.12.20

+ Recent posts