LLM을 어설픈 챗봇으로 경험하는 대중과 대규모 작업을 맡기는 전문 사용자 사이에서 능력에 대한 인식 격차가 커지고 있으며, 활용 분야와 시스템 접근 수준에 따라 경험이 크게 달라짐

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

• LLM을 어설픈 챗봇으로 경험하는 대중과 대규모 작업을 맡기는 전문 사용자 사이에서 능력에 대한 인식 격차가 커지고 있으며, 활용 분야와 시스템 접근 수준에 따라 경험이 크게 달라짐
• Karpathy의 대략적 추산으로 약 60억 명은 LLM을 거의 접하지 않았고, 약 10억~20억 명은 무료 챗봇을 검색과 글쓰기 보조 수단으로 가끔 사용
• 수학과 코드 분야의 전문 사용자 약 2,000만 명은 과거 수주~수개월 걸리던 복잡한 프로젝트를 에이전트가 프롬프트로 완수하는 변화를 직접 경험
• 내부 최첨단 시스템에 접근하는 약 5,000명은 수천 에이전트가 수주간 협업하는 작업을 접하고 있으며, 인간의 검토와 이해가 결과물 생산 속도를 따라가지 못하기 시작
• 격차를 만드는 요인은 문제의 규모와 작업 기간, 디지털 환경에서 검증 가능한 분야에 집중된 역량, 무료/유료/내부 시스템 사이의 접근 차이가 함께 만들어 냄

LLM 체감 역량의 네 단계

• Andrej Karpathy는 4월의 트윗을 다시 꺼내며, LLM 역량에 대한 이해의 격차가 더 커지고 있다고 봄
• 인구와 비율은 대략적 추산이며, 경험 수준에 따라 다음 네 단계로 나뉨
• LLM을 거의 접하지 않은 약 60억 명
  • 인구의 약 75% 는 LLM을 거의 접하지 않음
• 무료 챗봇을 가끔 쓰는 약 10억~20억 명
  • 약 20% 는 무료 ChatGPT류 제품을 가끔 사용함
  • 어설픈 챗봇을 조금 더 나은 Google 검색이나 글쓰기 보조 도구처럼 쓰며, 에이전트가 항공편 예약을 시도하는 정도를 경험할 수 있음
  • Karpathy의 비기술 분야 친구 중에는 별 쓸모가 없다고 말하는 사람이 있으며, 수학과 코드 이외 분야의 전문가 상당수도 이 단계에 속함
  • 임원과 여러 직무의 종사자는 사람들과 대화하는 데 많은 시간을 쓰므로, 변화를 지적으로 이해하더라도 경험은 간접적이고 다소 추상적임
• 최첨단 LLM을 전문적으로 활용하는 약 2,000만 명
  • 약 0.2% 는 수학과 코드 분야에서 최첨단 LLM을 전문적으로 활용함
  • 과거 수주~수개월 걸리던 대규모 복잡한 작업을 에이전트가 프롬프트로 완수하는 모습을 직접 봄
    • 사례로 앱 제작, 복제, 번역, 바이너리에서 앱 역컴파일이 있음
  • 변화는 매우 최근에 빠르게 일어났으며, Karpathy도 1년이 채 되지 않은 시점에는 코드를 한 글자씩 직접 입력하고 가끔 Tab 자동완성을 사용했음
• 내부 최첨단 시스템에 접근하는 약 5,000명
  • 약 0.00006% 는 내부 최첨단 시스템에 접근함
  • 외부에도 일부 선공개된 모습은 수천 에이전트가 수주간 대형 소프트웨어 프로젝트에서 협업하는 형태임
  • 제로데이 취약점 발굴, 기계 속도의 사이버 공격과 방어, 새로운 과학 발견, 수학의 최전선 확장 등 업계 최고 전문가에게도 수년이 걸렸을 작업을 수행함
  • 인간의 검토와 이해는 뒤처지기 시작함
  • 수개월 전 OpenAI-HF 사건은 여전히 사람들이 경위를 발굴하고 분석하고 있음
  • 최첨단 수학을 다룬 722편의 원고를 수학자들이 검토하는 데도 한동안 시간이 걸릴 수 있음

깔때기를 만드는 세 요인

• 야심, 문제 규모, 작업 기간이 커질수록 영향도 커짐
  • 한 문단으로 답할 질문은 시스템의 역량을 거의 시험하지 못하며, 자신에게 중요한 크고 어려운 문제들이 충분히 있어야 함
  • 이 요인이 소비자와 전문 사용자 사이의 격차를 만듦
• 분야별 역량의 불균일성 때문에 디지털 환경에서 검증 가능하고 경제적 가치가 높은 분야에 성능의 정점이 집중됨
  • LLM 역량은 수익 잠재력을 기준으로 구성한 환경들의 조합에서 검증 가능한 보상을 사용하는 강화학습으로 형성됨
  • 이 요인이 수학과 코드 같은 활용 분야에 따른 격차를 주로 만듦
• 접근 권한도 무료, 유료, 내부 시스템 사용자 사이의 차이를 만듦
• 대중 대부분은 시스템을 접하지 않았거나 어설픈 챗봇으로 경험하고, 전문가 다수는 소폭의 개선만 체감하는 반면, 극소수 전문가는 거의 수직으로 상승하는 변화에 현기증을 느끼는 상황이 동시에 벌어지고 있음

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

🧠 매일 집중하기가 점점 어려워지는 이유

핵심 요약: 과거와 달리 프로그래밍, 학습, 글쓰기 등 단 하나의 활동에 1시간조차 집중하기 어려워졌습니다. 이는 지루함을 피하게 만드는 환경적 선택지, 직장 업무 방식, 그리고 LLM(AI)이 가져온 과잉 자극이 복합적으로 작용한 결과입니다.

1. 한 시간도 이어가기 어려운 집중력

• 산만한 상태의 반복: 10분마다 작업에서 이탈하며, 수동적인 강제 장치(예: 15분 타이머)가 없으면 금세 다른 행동으로 주의가 옮겨감.
• 불편함을 피하려는 뇌: 지루하거나 10분 이상 고민해야 하는 난관을 만나면 휴대폰 확인, 물 마시기, 집안일(침대 정리 등)로 도망침.
• 진짜 목표: 주 90시간 노동이 아니라, 단 1시간이라도 방해 없이 온전히 하나의 활동에 몰입하는 습관을 찾는 것.

2. 주의 이탈의 변화 과정

• 침대 속 휴대폰 ➔ 컴퓨터 탐색으로 전이: * 초기에는 침대 충전기를 없애는 규칙 등으로 휴대폰 사용을 통제함.
  • 그러나 Hacker News, YouTube 등 무의미한 웹 탐색과 저품질 클릭베이트 콘텐츠가 습관적으로 컴퓨터 앞 주의력을 빼앗음.
• 지루함을 참는 능력의 퇴화: 과거에는 대수 문제를 끝까지 스스로 풀며 깊이 이해하려 했으나, 점차 지루함을 피할 쉬운 대안들이 늘어나면서 깊은 사고를 유지하기 어려워짐.

3. 집중을 방해하는 두 가지 주범

🏢 ① 회의와 채팅 중심의 직장 환경

• 하루 대부분을 회의와 Slack 채팅에 소비함 (실제 시간 추적 결과 일주일에 Slack에만 8시간 사용).
• 깊은 사고 없이 대화와 소통만으로도 '일하는 것처럼' 보이는 환경이 산만한 업무 습관을 강화함.

🤖 ② LLM(AI)이 부추기는 새로운 멀티태스킹과 과잉 자극

• 맥락 유사의 과부하: 작업을 위임한 후에도 AI의 결과를 계속 생각하고 교정해야 하므로 머릿속에 여러 맥락을 유지하게 됨.
• 즉각적 보상의 중독: * AI를 활용한 '바이브 코딩'이나 빠른 결과 생성은 즉각적인 자극을 줌.
  • 이로 인해 며칠씩 걸리는 긴 작업이나 직접 논문을 읽고 고민해야 하는 과정을 지루하게 느끼게 됨.
• 동기 저하: 막힐 때마다 AI에 의존하면서 문제를 스스로 깊이 해결하려는 습관이 약화됨.

4. 집중력을 되찾기 위한 시도와 대안

• 시작을 돕는 강제 장치: 15분 타이머를 설정해 글쓰기/작업의 초기 동기를 형성.
• 환경 차단 및 라이브 스트리밍: 작업 과정을 방송하여 스스로 딴짓을 하지 못하도록 강제.
• '쉽게 멈출 수 있는' 대체 활동 찾기:
  • 동기가 없을 때 스마트폰/영화 대신 독서나 정원 가꾸기(흙 옮기기, 식물 다듬기)를 수행.
  • 이러한 활동은 도파민 중독성이 낮아, 동기가 돌아왔을 때 쉽게 멈추고 원래 작업으로 복귀할 수 있음.

💡 결론: > 즉각적인 해답이나 생산성 툴을 찾는 것보다, 지난 시간 동안 내가 왜 작은 일조차 지속하지 못했는지 주의 이탈의 경로와 습관을 먼저 인지하고 교정하는 것이 핵심입니다.

벡터 DB 만들어 보기

https://wikidocs.net/262584

벡터 데이터베이스 정의

벡터 데이터베이스는 데이터 객체의 수치적 표현인 벡터(벡터 임베딩이라고도 함) 형태로 정보를 저장하는 데이터베이스입니다. 이러한 벡터 임베딩의 성능을 활용하여 이미지, 텍스트, 센서 데이터 등의 비정형 데이터 및 반정형 데이터로 구성된 대규모 데이터 세트를 색인하고 검색합니다. 벡터 데이터베이스는 벡터 임베딩을 관리하기 위해 구축되었으므로 비정형 및 반정형 데이터 관리를 위한 완벽한 솔루션을 제공합니다.

벡터 데이터베이스는 벡터 검색 라이브러리 또는 벡터 인덱스와 다릅니다. 이는 메타데이터 저장 및 필터링을 가능하게 하고, 확장 가능하며, 동적 데이터 변경을 허용하고, 백업을 수행하고, 보안 기능을 제공하는 데이터 관리 솔루션입니다.

벡터 데이터베이스는 고차원 벡터를 통해 데이터를 구성합니다. 고차원 벡터에는 수백 개의 차원이 포함되어 있으며 각 차원은 그것이 나타내는 데이터 객체의 특정 기능이나 속성에 해당합니다.

벡터 임베딩이란 무엇인가요?

벡터 임베딩은 주제, 단어, 이미지 또는 기타 데이터를 숫자로 표현한 것입니다. 임베딩이라고도 하는 벡터 임베딩은 대규모 언어 모델 및 기타 AI 모델에 의해 생성됩니다.

각 벡터 임베딩 사이의 거리는 벡터 데이터베이스 또는 벡터 검색 엔진이 벡터 간의 유사성을 결정할 수 있게 해줍니다. 거리는 데이터 객체의 여러 차원을 나타낼 수 있으므로,머신 러닝 및 AI가 패턴, 관계 및 기본 구조를 이해할 수 있습니다.

DB-Engines Ranking of Vector DBMS 

https://db-engines.com/en/ranking/vector+dbms

데이터 저장 및 읽기까지 9단계 과정 필요

통상 벡터 DB에 데이터를 저장하고 이를 읽어오기까지는 9단계 과정이 필요하다. 기업이 자체적으로 작성한 신입사원 백서 파일을 벡터 DB에 저장하고 신입사원이 기업 전용 생성형 AI 챗봇에 질의하고 받기까지 과정을 예로 들어 보자. 먼저 구축된 벡터 DB에 덩어리(청크, Chunk) 형태로 백서 파일을 변환해야 한다. 청크는 의미 있는 단위로 나누는 것을 의미한다. 이후 청크 형태로 바뀐 신입사원 백서 데이터를 임베딩 모델에 넣어 벡터화한다. 이렇게 벡터화된 신입사원 백서 데이터를 벡터 DB에 넣기 전 인덱싱(Indexing)을 통해 정렬하고 벡터 DB에 저장한다. 여기까지가 신입사원 백서 파일을 벡터화하고 벡터 DB에 저장하는 과정으로 볼 수 있다. 이때 사내 규정 및 거버넌스가 바뀌면서 백서가 수정될 경우 벡터 DB에 실시간으로 반영할 수 있어야 한다.


벡터 DB와 지식그래프 비교 (출처: medium.aiplanet.com)
이후 신입사원이 기업용 생성형 AI 챗봇에 입사 첫해 여름휴가를 최대 며칠까지 사용할 수 있는지 질의한다면, LLM과 연동된 랭체인을 통해 쿼리를 임베딩 모델에 넣어 벡터화한다. 이후 벡터화된 질의문을 벡터 DB 내 인덱스에서 유사 벡터 군집(휴가에 대한 정보들) 및 벡터 데이터(입사 첫해 여름휴가 정보)를 찾고 이를 다시 LLM에 보내 사용자가 이해할 수 있는 답변으로 치환해 보여주는 방식이다. 이러한 과정은 타 DB와 별다른 차이점이 없다.
 

다음은 벡터 DB를 생성하는 코드입니다.

# build_vector_db.py
from langchain_community.document_loaders.csv_loader import CSVLoader
from langchain_community.vectorstores import Chroma
from langchain_upstage import UpstageEmbeddings

loader = CSVLoader(
    file_path="./csv/한국산업은행_금융 관련 용어_20151231.csv", encoding="cp949"
)
pages = loader.load()
print(pages[:2])

us_model =  UpstageEmbeddings(
    api_key="up_ULzGbJVs57bcnNHm8D0KdI51Nzl4F",
    model="solar-embedding-1-large"
)

Chroma.from_documents(pages, us_model, persist_directory="./database")

코드 블록별로 설명하면 아래과 같습니다.

• CSV 파일 로드

실습에 사용되는 파일을 로드합니다. CSVLoader 객체를 사용하여 CSV 파일을 로드하고, 반환된 Document 정보를 pages 변수에 저장합니다. 다음 코드는 CSV 파일을 출력하고 샘플 데이터를 출력하는 내용입니다.

loader = CSVLoader(file_path="./csv/한국산업은행_금융 관련 용어_20151231.csv", encoding='cp949')
pages = loader.load()

print(pages[:2])

[Document(metadata={'source': './csv/한국산업은행_금융 관련 용어_20151231.csv', 'row': 0}, page_content='구분: 리스크\n분류: 리스크 개요\n용어: 리스크(Risk)\n설명: 미래수익 또는 자산가치 변동
의 불확실성(Uncertainty)으로 인하여 보유자산에서 손실이 발생할 가능성(신용  시장  금리  유동성리스크 등) 또한 부적절하거나 잘못된 내부절차  시스템 오류  직원의 실수·고의 또는 자연재해 등의 사 건에 의해 손실이 발생할 가능성 (운영리스크 등)'), Document(metadata={'source': './csv/한국산업은행_금융 관련 용어_20151231.csv', 'row': 1}, page_content='구분: 리스크\n분류: 리스크 개요\n용어: 불확실성\n설명: 설사 손실이 발생한다 해도 발생될 것이 확실하고 크기(금액)도 확실히 알 수 있어서 회피 또는 수용하기로 의사결정하고 나면 그것은 더 이상 리스크가 아님')]

• 임베딩 모델 로딩

업스테이지 랭체인 인터페이스를 사용해서 solar-embedding-1-large 모델을 로딩합니다.

us_model = UpstageEmbeddings(
    api_key="발급받은 키",
    model="solar-embedding-1-large"
)

• 벡터 DB 생성

Chroma.from_documents 메서드를 호출해서 로딩한 문서를 임베딩 모델을 통해 임베딩 벡터로 변환하고 이것을 최종적으로 로컬 디렉터리에 저장합니다.

Chroma.from_documents(pages, us_model, persist_directory="./database")

이 명령이 실행되고 나면 임베딩 벡터 외에도 원문 정보, 인덱스, 메타 데이터 등의 각종 정보를 바탕으로 로컬 디렉터리에 데이터베이스가 구성됩니다. 다음은 로컬에 생성된 데이터베이스를 캡처한 자료입니다.

**"Hallucination" (환각)** 할루시네이션 은  인공지능, 특히 대규모 언어 모델(Large Language Model, LLM)과 같은 생성형 AI 분야에서 사용되는 중요한 용어입니다.

Hallucination은 LLM이 사실과 다르거나, 논리적으로 불가능하거나, 학습 데이터에 존재하지 않는 정보를 마치 사실인 것처럼 자신 있게 생성하는 현상을 의미합니다. 쉽게 말해, AI가 '없는 것을 지어내는 것' 또는 **'거짓말을 하는 것'**과 같습니다.

왜 Hallucination이 발생할까요?

LLM은 방대한 양의 텍스트 데이터를 학습하여 단어와 문장 사이의 통계적 패턴과 관계를 배웁니다. 이를 통해 다음 올 단어를 예측하고 문장을 생성합니다. Hallucination이 발생하는 주요 이유는 다음과 같습니다.

1. 패턴 학습의 한계:
   • LLM은 '세상에 대한 이해'를 하는 것이 아니라, '단어 시퀀스의 통계적 패턴'을 학습합니다. 따라서 특정 질문에 대해 학습 데이터에서 유사한 패턴을 찾지 못하거나, 불완전한 패턴을 발견했을 때, 가장 그럴듯한(통계적으로 유사한) 단어 시퀀스를 조합하여 생성하게 됩니다. 이 과정에서 사실과 동떨어진 내용이 나올 수 있습니다.
2. 데이터 부족 또는 편향:
   • 특정 주제에 대한 학습 데이터가 부족하거나, 데이터 자체가 편향되어 있다면, 모델은 부정확하거나 존재하지 않는 정보를 생성할 가능성이 높아집니다.
3. 최신 정보 부족:
   • LLM은 학습 데이터가 업데이트된 시점 이후의 최신 정보를 알지 못합니다. 따라서 최신 사건이나 사실에 대해 질문을 받으면, 과거 데이터를 기반으로 그럴듯하지만 틀린 답변을 생성할 수 있습니다.
4. 불분명하거나 모호한 프롬프트:
   • 사용자의 질문(프롬프트)이 너무 추상적이거나 모호할 경우, LLM은 질문의 의도를 정확히 파악하기 어렵고, 이로 인해 잘못된 방향으로 정보를 생성할 수 있습니다.
5. 과도한 일반화:
   • 모델이 학습 과정에서 본 일부 패턴을 과도하게 일반화하여, 실제로는 적용되지 않는 상황에 잘못된 정보를 생성할 수 있습니다.

Hallucination의 문제점

• 신뢰성 저하: AI가 사실과 다른 정보를 생성하면 사용자는 AI의 답변을 신뢰하기 어렵게 됩니다.
• 잘못된 의사결정: AI의 잘못된 정보를 기반으로 중요한 결정을 내릴 경우 심각한 결과를 초래할 수 있습니다.
• 확인 노력 증가: 사용자는 AI가 생성한 모든 정보를 일일이 사실인지 확인해야 하는 추가적인 부담을 안게 됩니다.

Hallucination을 줄이는 방법

Hallucination을 완전히 없애는 것은 현재 LLM 기술의 큰 과제이지만, 다음과 같은 방법들로 그 발생 빈도와 심각도를 줄일 수 있습니다.

• RAG (Retrieval-Augmented Generation): 외부의 신뢰할 수 있는 최신 정보를 검색하여 LLM에 제공함으로써 LLM이 '참조할 자료'를 기반으로 답변을 생성하게 합니다. (위에서 설명한 내용입니다!)
• 정확한 프롬프트 엔지니어링: 질문을 명확하고 구체적으로 작성하여 LLM이 정확한 의도를 파악하도록 돕습니다.
• 모델 재학습(Fine-tuning) 및 업데이트: LLM을 최신 데이터로 주기적으로 재학습시키거나, 특정 도메인에 특화된 데이터로 파인튜닝하여 해당 분야의 정확도를 높입니다.
• 불확실성 표시: LLM이 자신이 생성한 정보에 대해 얼마나 확신하는지를 사용자에게 알려주어, 불확실한 정보는 사용자가 한 번 더 확인할 수 있도록 유도합니다.
• 인간 개입 및 검증: 중요한 의사결정이나 민감한 정보의 경우, AI의 답변을 사람이 최종적으로 검증하고 수정하는 단계를 거칩니다.

Hallucination은 LLM을 실생활에 적용할 때 가장 주의해야 할 부분 중 하나이며, RAG와 같은 기술의 발전으로 그 영향력을 줄이려는 노력이 계속되고 있습니다.

CxO 또는 기술 전략 담당자라면 지난 몇 달 동안 AI에 대한 태도가 변화했을 가능성이 크다. 거대 기업의 생성형 AI 서비스가 헤밍웨이와 같은 이메일/문자 품질을 만들어줄 것이라고 기대하지 않으며, 이러한 서비스가 전반적인 수익과 주가를 높여줄 것이라고 기대하지도 않는다. GPU 칩도 일개 하드웨어로 무심히 바라보게 됐을 것이다. 그렇다고 해서 AI를 포기했다는 의미는 아니다. 현실을 직시했다는 뜻이다. 그렇다면 실제 행동 측면에서 현실의 기업들은 어떤 모습일까? '현실의' AI란 무엇일까?

일단은 점점 더 사내에서 실행하는 애플리케이션을 향해가고 있다. AI 계획을 공유한 292개 기업 중에서 164개 기업은 자체 호스팅 AI를 통해서 진정한 AI 혜택이을 얻을 수 있을 것으로 예상했다. 또 105개 기업만이 AI에 대해 잘 알고 있다고 답했고, 47개 기업은 확신을 가지고 있다고 답했다. 전반적으로 사내 AI(in-house AI)가 초기 단계에 있다고 말하는 것은 정확한 표현이다. 기업 내 AI 배포에는 많은 영역이 있으며 대부분이 아직 혼란스럽기 때문이다.

이러한 어려움에도 불구하고 벤더들은 셀프 호스팅 옵션을 내세우는 듯하다. 시스코와 주니퍼( HPE의 인수가 순조롭게 진행되고 있음)는 모두 엔터프라이즈 데이터센터에서의 AI에 더 집중하겠다는 의사를 밝혔다. AI 모델 제공업체들도 생성형 AI 도구의 라이선스를 강조한다. 두 그룹 모두 기업들의 구매를 고대하고 있지만, 앞서 언급한 혼란으로 인해 기업 대부분은 어떻게 시작해야 할지조차 모른다.

전반적으로 기업들은 AI 호스팅 계획의 시작으로 GPU와 데이터센터 장비를 생각하곤 한다. 그러나 응답을 분석한 결과 앞선 기업들은 그렇지 않다고 말하고 있었다. “애플리케이션 요구 사항에 대한 예상에 맞춰 하드웨어를 구매하면 안 된다. AI가 수행하기를 원하는 작업부터 시작한 다음 어떤 AI 소프트웨어가 필요한지 물어봐야 한다. 그런 다음 데이터센터 계획을 시작할 수 있다”라고 한 CIO는 말했다.
 

LLM과 SLM 비교
자체 AI 호스팅 경험을 가진 기업 다수는 챗GPT로 시작했다고 전한다. 퍼블릭 AI 서비스 중 하나에서 사용되는 대규모 언어 모델(LLM)의 프라이빗 버전을 호스팅해야 한다고 가정하는 것이다. 기업 3분의 1은 이러한 경로를 밟고 있었다. 그러나 3분의 2는 자체 호스팅하는 AI가 '오픈소스' 모델을 기반으로 해야 한다고 생각하고 있었다. 또 이들 중 대부분은 이제 특정 미션에 '전문화'된 AI 모델을 찾고자 한다고 응답했다. 

오늘날 사내 구현 형태로 제안될 가능성이 가장 큰 AI 프로젝트는 AI 챗봇이었다. 비즈니스 사례로서의 성공 가능성도 크다고 할 수 있다. 이러한 프로젝트는 대개 사전 판매 및 판매 후 미션, 즉 마케팅/영업 및 고객 지원을 목표로 한다. 이러한 애플리케이션을 우선적으로 고려하는 기업은 퍼블릭 AI 서비스나 클라우드 호스팅을 고려할 가능성이 높았다. 즉 독점 모델을 유지하는 기업들인 1/3의 대부분을 차지하고 있었다.

비즈니스 사례를 만들 가능성이 다음으로 높은 AI 애플리케이션 분야는 비즈니스 분석 및 인텔리전스다. 대부분의 기업이 AI를 자체 호스팅해야 한다고 처음부터 생각하는 분야이기도 하다. IBM 고객들은 이 분야에서 IBM의 왓슨X 전략을 이용하는 경향이 있으며, 모든 기업 중에서 모델 선택 방식에 가장 큰 자신감을 보이고 있었다. 다른 기업들 사이에서는 메타의 라마가 블룸과 팔콘 모델을 제치고 가장 선호하는 전략이 됐다. 하지만 이러한 변화는 상당히 최근에 나타났기 때문에 계획 측면에서는 앞서 있지만 구축은 뒤처져 있었다.

한편 고객 대면 업무의 챗봇 사용자, 의료 업계 종사자, 심지어 비즈니스 분석 분야에서 AI를 계획하는 많은 기업들이 소규모 언어 모델(SLM)에 점점 더 많은 관심을 보이고 있다. SLM은 특정 임무에 맞게 학습된다. 덕분에 환각의 위험을 획기적으로 줄이고 전문 영역에서 더 유용한 결과를 생성할 수 있다. 몇몇 SLM은 기본적으로 특수 임무에 맞게 조정된 LLM이기에 적당한 LLM을 선택하면 SLM 선택이 끝난다. AI 전략에 대해 신뢰할 수 있는 공급업체가 있다면 해당 공급업체와 미션별 SLM에 대해 논의하는 것이 현명한 수순이다. 전문 SLM을 사용해 본 기업(총 14개)은 SLM이 현명한 선택이었으며 호스팅 비용을 크게 절감할 수 있다는 데 동의했다.

GPU 및 이더넷 네트워크
하드웨어는 어떨까? 엔비디아 GPU를 떠올리기 쉽지만 기업들이 실제 구매하는 기기는 GPU가 포함된 서버다. 델이나 HPE, 슈퍼마이크로와 같은 벤더들이 기업의 GPU 정책에 영향을 끼친다. 기업들은 AI 호스팅을 위해 약 50개에서 거의 600개까지 다양한 수의 GPU를 보유하고 있었으며, 100개 미만의 GPU를 보유한 기업의 3분의 2가 초기 테스트 중에 추가했다고 보고했다. 500개 이상을 보유한 기업 중 일부는 현재 너무 많다고 생각하고 있었다. 대부분의 엔터프라이즈 셀프 호스팅 계획자는 200~400개 사이를 배포할 것으로 예상했으며, 450개 이상을 사용할 것이라고 답한 기업은 단 두 곳에 그쳤다.

GPU를 직접 설치하려는 기업은 거의 없었다. 즉 표준 서버용 GPU 보드를 구매하려는 경우는 드물었다. 그저 끼운다고 끝이 아님을 잘 알고 있기 때문일 터다. 좋은 GPU에는 빠른 메모리, 빠른 버스 아키텍처, 빠른 I/O 및 네트워크 어댑터가 필요하다.

한편 이더넷을 사용할지 인피니밴드를 사용할지에 대한 오래된 논란은 자체 호스팅 AI를 사용 중이거나 계획 중인 기업들에게 그리 고민거리가 아니었다. 이들은 이더넷이 정답이라는 데 동의하며, 가능한 한 빨라야 한다는 데도 동의했다. 우선순위 흐름 제어와 명시적 혼잡 알림 기능을 모두 갖춘 800G 이더넷은 기업에서 권장하고 있으며, 화이트박스 장치로도 제공되고 있다. 

기업들은 또 AI를 표준 서버와 혼용해서는 안 된다는 데 동의하고 있었다. AI 배포를 자체 고속 클러스터 네트워크를 갖춘 새로운 클러스터로 볼 수 있는 셈이다. 또한 학습이나 프롬프트 등 회사 데이터에 액세스하기 위해 데이터센터에 빠르게 연결하고 사용자 액세스를 위해 VPN에 연결하는 것이 중요하다.

여러 개의 AI 애플리케이션을 사용할 예정이라면 두 개 이상의 AI 클러스터가 필요할 수 있다. 필요에 따라 SLM 또는 LLM을 클러스터에 로드할 수는 있지만, 데이터를 보호하면서 동일한 클러스터에서 여러 모델을 동시에 실행하는 작업은 더 복잡하다. 

일부 기업에서는 하나의 LLM 도구를 선택하여 고객 지원, 재무 분석 및 기타 애플리케이션에 맞게 학습시킨 다음 다른 애플리케이션에 병렬로 사용할 수 있다고 생각하고 있었다. 문제는 응답을 격리하는 것이 어렵다는 점이다. 모델 내에서 미션을 혼합하는 것은 현명하지 않을 가능성이 크다.

그렇다면 최종 권장 사항은 무엇일까? 테스트... 테스트… .테스트다. 시간을 들여 모델 옵션을 평가해야 한다. 시간을 들여 구성을 선택하고, 특히 커밋하기 전에 AI를 시험해 볼 수 있을 때 가능한 한 자주 테스트하라. AI 전략을 수립한 후에는 제품, 비즈니스, 운영 중인 세금 및 규제 프레임워크의 변화에 따라 모델을 최신 상태로 유지할 수 있도록 계속 테스트하라. AI는 인간과 마찬가지로 상황이 변화함에 따라 재교육을 필요로 한다 그리고 인간 또한 AI에 대한 새로운 시각을 지속적으로 업데이트해야 한다. 

https://www.ciokorea.com/news/349969