< 생성형 AI >
대규모 데이터에서 학습한 패턴을 활용해 텍스트, 이미지, 코드 등 새 결과물을 만들어내는 모델 계열
# 빅데이터는 사람이 다루기엔 너무 많음 → AI의 발달
- 핵심 가치: 작성 시간 단축, 표준화된 산출물, 근거와 형식의 일관성 강화, 반복 작업의 품질 향상
- 좋은 결과의 절반은 입력 품질(데이터 정제)로 결정
- (생성형)AI 구성 4요소
n 모델: 많은 예시를 통해 언어/이미지의 일반적 패턴을 체득한 생성 엔진
n 프롬프트: 무엇을 만들어야 하는지, 어떤 제약이 있는지 지시하는 설명서
# 컨설턴트라면 프롬프트를 많이 다룰 듯?
n 컨텍스트: 정답에 필요한 배경지식/예시를 추가로 제공하는 참고 자료
n 피드백 루프: 결과를 점검하고 보안 질문/수정을 반복하는 품질 관리 절차
# AI는 만드는 순간에도(데이터를 학습하는 순간) 실시간으로 ‘중고’가 된다. 계속 개선 필요
NLP (Natural Language Processing) : 자연어(인간의 언어) 처리 #컴퓨터 언어로 전환
Transformer : Attention알고리즘 통해 병렬처리 지원, context를 잘 유지할 수 있게
LLM (Large Language Model) : 텍스트 기반으로 언어를 입력 받고 출력 → 비디오나 이미지는 그 다음 단계 # ex. GPT
- 텍스트를 토큰 단위로 처리하고, 포지션과 Self_Attention으로 문맥을 구성
- Transformer 구조를 기반으로 문맥을 이해하고 새로운 텍스트를 생성
# AI 기술은 답을 생성X, 확률 높은 문장or답을 출력
전체 흐름: transformer에서 입력 받아서 처리하고, LLM에서 확률 높은 값으로 문장 잘 가다듬어서 텍스트로 반환한다.
# transformer : Incoder에 입력값 주면 임베딩, 인코딩 후 context를 Encoder에 전달 → 가장 높은 확률의 단어를 출력해서 문장을 완성
Embedding : 자연어 → 벡터
Encoding : 자연어 → 숫자
Decoding : 숫자 → 자연어
토큰(Token): 모델이 이해하는 최소 단위(문자, 음절 단어 조각 등)
토크나이저(Tokenizer): 텍스트를 토큰으로 쪼개고 다시 문자열로 복원하는 도구
- 입력 길이, 연산 비용 및 속도, 출력 안정성에 직접 영향
- 작업 포인트
1. 동일 문장도 토크나이저에 따라 토큰 수 다름 → 컨텍스트 예산 관리 필요
2. 데이터 전처리로 불필요 토큰 증가 방지(불필요한 특수문자, 공백 등을 미리 정리)
→ 자연어 처리의 가장 어려운 부분
Context Window : 모델이 한 번에 참고할 수 있는 입력 길이 한계
- 길이 초과 시 앞부분이 잘리거나 생략됨 → 절단 대비 중요 섹션을 먼저 배치, 핵심 지시와 스키마를 앞쪽에 배치
Positional Encoding : 단어 벡터(embedding)에 위치 정보 추가 → 단어 벡터 + 위치 벡터(인덱스)
- 문맥 유지가 품질에 영향을 미치기 때문에 작업 성능이 결과 성능에도 큰 영향 끼침
Self-Attention : 입력 받은 내용에 대해서 어떠 부분에 더 집중해야 되는가(중요한가) 뽑아내는 것
Incoder : 분석이나 생성을 위해서 컨텍스트를 잘 꾸리는 건 인코더 강화
Decoder : 채팅을 통해서 사용자에게 텍스트나 어떤 결과물을 잘 전달하기 위해서 쓰는 형태는 디코더 강화 ex. gpt
생성형 AI의 텍스트 생성 과정: 입력 받기 → 확률 분포 계산 → 단어 선택 → 반복 → 문장 완성
그렇다면 좋은 출력을 얻으려면 어떻게 입력을 설계해야 하는가?
1. Prompt (지시문) – 출력 품질을 좌우하는 입력값
모델에게 역할, 목표, 제약 출력 형식을 알려주는 사용 설명서
2. Context (참고 지식)
정답에 필요한 배경지식과 작성 예시를 추가 제공 (많이 넣기 보다는 관련도 높은 핵심 내용만 선별)
# 현재 트렌드는 prompt 엔지니어링에서 context 엔지니어링으로 넘어가는 추세 (Reasoning AI의 대세=추론형 AI)
좋은 입력 = 좋은 출력
LLM은 입력을 어떻게 주느냐에 따라 답변 품질이 결정 # 대표 실패 유형: 환각(Hallucination)
< RAG >
기존 LLM(챗 gpt)의 한계는 사전학습 된 모델이라는 것(중고, 최신 데이터는 반영X) → 이를 해결하기 위해 gpt는 ‘웹 검색’을 활용
RAG (Retrieval-Augmented Generation) # 검색 증강 생성
- 답을 만들 때 외부 문서나 데이터베이스를 검색해서 참고한 뒤 답변에 포함 # 웹검색X
- 가장 큰 특징 = 객관성 # 데이터베이스는 실제 데이터이기 때문에 ‘환각’ 감소
즉, RAG는 문서에서 확인해서 인용과 링크로 검증 경로 제공(객관성 신뢰 확보)
RAG Pipeline 프로세스 단계
1. 질의(Quary) 정제 # Quary는 벡터 형태로 입력되는 사용자의 질문(요청)
2. 후보 검색
3. 관련 청크 선택 및 재순위
4. 생성 및 인용
5. 품질 점검
청크 (Chunk): 검색과 생성의 최소 단위
긴 문서를 잘게 쪼갠 덩어리 → 하나의 덩어리가 스스로 읽혀도 의미를 이해할 수 있어야 함
# 하나의 청크는 하나의 주제만 포함해야 함
임베딩과 인덱스의 필요성 # 임베딩: 자연어 → 벡터
- 인덱스(Index): 수천~수만 개의 벡터 중 가장 가까운 의미를 빠르게 찾기 위한 구조
- 유사도 측정: 제2코사인 법칙(각도)를 기준으로 두 벡터의 방향이 얼마나 비슷한지 계산 → 가장 가까운 것 선택(검색에 이용)
RAG의 흐름: 데이터 입력 → 임베딩/인덱싱 → 사용자 질의 임베딩해서 검색 → 인용 만들고 답변 생성
< Agent System >
Agent : LLM 대신에 처리해주는 도구
- 작동 순서: 계획 → 도구 호출 → 결과 확인 → 재계획
# 필수는 아니지만 추론 AI가 유리
- 계획 전략
1. ReAct: “생각과 행동을 번갈아” 반복 진행 → 툴 호출 → 관찰로 다음 행동 결정
2. Plan-and-Execute: 초기에 전체 계획을 세우고 실행 단계에서 보정
3. Routing: 질문 유형에 따라 다른 프롬프트나 도구 세트를 선택
도구(Tool): Agent가 스스로 할 수 없는 일을 대신 수행하게 해주는 외부 기능
< Prompt Engineering >
프롬프트 엔지니어링: 프롬프트는 모델에게 역할, 목표, 제약, 단계, 출력 형식을 명시하는 지시문
- 같은 모델이라도 프롬프트가 구조화되면 품질 편차가 줄어들고 승인 속도가 빨라짐
- 출력 스키마 설계: 표 또는 JSON
- 예시 주입: Few-shot, Zero-shot, Counter-example
- 단계 지시: 생각의 순서를 외부로 드러내며 누락과 모순을 줄임
- 길이 관리: 최대 토큰 수 또는 문장 수를 명시하여 장황한 출력 방지 # 토큰 비용 절감
- 중단 제어(Stop sequence): 불필요한 이어쓰기를 막기 위한 중단 토큰 지정
< Context Engineering >
컨텍스트 엔지니어링: 정답에 필요한 정보만 선별하여 구조적으로 입력에 주입하는 설계
- 컨텍스트 압축과 청크 정렬은 짧고 정확하게
- 정렬 규칙: 질문과 직접 연관되는 청크 앞쪽에 배치, 중요도와 최신성으로 우선수위 결정
- 인용과 출처 관리 # 출처는 반드시 직접 검증할 것 (환각 주의)
< MCP : Model Context Protocol >
MCP: LLM이 도구, 데이터, 프롬프트 템플릿에 표준화된 방법으로 접근하도록 도와주는 “중간 통신 규약”
- LLM의 입력창에 “모든 것”을 넣는 대신 필요한 순간에 필요한 리소스만 표준 인터페이스로 불러와서 사용
- Agent Workflow 와 비슷, 다만 특정 어플리케이션(서버)에 접속된 형태
# Agent workflow는 내 입맛대로 커스터마이징 가능한 장점
- MCP 서버: 도구와 리소스와 프롬프트를 카탈로그로 노출하는 서비스
- MCP 클라이언트: 모델 측에서 MCP 서버와 대화하는 어댑터