AIP를 이용한 텍스트 감정 분석
감정 분석(Sentiment analysis)은 리뷰, 소셜 게시물이나 피드백에 나타난 긍정과 부정, 정서 표현을 분류하는 작업입니다. 고객 의견에서 제품과 서비스의 개선점을 찾거나 시장 반응을 조사하고, 금융 관련 문서의 정서 지표를 동향 연구에 사용할 수 있습니다.
분석 결과를 무엇에 사용할지 먼저 정합니다. 같은 문장도 평가 대상이 제품인지 배송 서비스인지에 따라 분류가 달라질 수 있으므로 입력 범위와 판단 기준을 함께 정의합니다.
전통적인 전처리
선택한 모델에 맞춰 텍스트를 처리합니다. 다음 예는 처리 단계를 설명하는 가상 입력이며 모든 분석에 동일하게 적용할 전처리 규칙은 아닙니다.
| 단계 | 처리와 예 |
|---|---|
| 토큰화(Tokenization) | I love apple pies!를 ["I", "love", "apple", "pies", "!"]처럼 단어와 기호로 나눕니다. 언어와 문맥에 따라 분리 규칙이 필요합니다. |
| 불용어 제거(Stop word removal) | 선택한 목록의 is, and, the 같은 단어를 제외합니다. 위 예에서 I를 제외하고 문장부호 !도 별도로 제거하면 ["love", "apple", "pies"]가 됩니다. |
| 어간 추출과 표제어 추출 | 단어 변형을 정규화합니다. loving을 love로 표현하는 것이 한 예입니다. 어간 추출은 형태를 줄이는 규칙을, 표제어 추출은 사전이나 품사 정보 등을 사용할 수 있으며 불규칙형과 문맥을 어떻게 처리하는지 확인합니다. |
불용어와 문장부호 제거는 서로 다른 처리입니다. 감정 분석에서는 부정어, 대문자나 느낌표가 결과에 영향을 줄 수 있습니다. 예를 들어 NLTK의 VADER는 부정 표현과 문장부호의 강조를 사용하므로 이 정보를 일률적으로 삭제하지 않습니다.
규칙과 학습 모델
규칙 기반 방식은 사람이 만든 단어 목록과 언어 규칙으로 분류합니다. 긍정 단어가 더 많으면 긍정으로 분류하는 방식이 한 예입니다. 목록을 관리해야 하고 문맥, 반어와 미묘한 표현을 처리하는 규칙이 부족하면 오분류할 수 있습니다.
지도 학습은 정답 레이블이 붙은 텍스트에서 특성과 감정의 관계를 학습합니다. 제품 리뷰에 Naive Bayes 분류기를 적용할 수 있습니다. 작업에 맞는 주석 데이터가 필요하며 수집 비용과 학습 데이터의 편향을 고려합니다.
비지도 학습은 명시적인 정답 없이 패턴을 찾습니다. k-means로 게시물을 묶을 수 있지만, 군집이 자동으로 긍정이나 부정을 뜻하는 것은 아닙니다. 잡음과 데이터 품질에 따라 군집의 해석이 달라집니다.
| 딥러닝 계열 | 감정 분석에서의 사용과 고려점 |
|---|---|
| CNN | 특징적인 구절과 패턴으로 문장을 분류합니다. 긴 문맥이나 순서에 걸친 관계를 얼마나 다루는지 확인합니다. |
| RNN 및 LSTM | 텍스트의 순서를 따라 정보를 처리합니다. 긴 입력의 계산 비용과 작은 학습 자료에서의 과적합을 고려합니다. |
| Transformer와 BERT | 사전학습 모델을 감정 분류 작업에 미세 조정하는 경로가 있습니다. 학습 자료, 연산 자원과 모델 조정 경험이 필요합니다. |
자주 쓰는 NLP 도구
| 도구 | 제공하는 기능과 선택 시 고려점 |
|---|---|
| NLTK | 말뭉치와 어휘 자료, 토큰화, 어간 추출, 태깅, 구문 분석과 분류 도구를 제공합니다. 연구와 교육뿐 아니라 선택한 분석기와 자료의 적합성을 평가하여 사용합니다. |
| TextBlob | 품사 태깅, 명사구 추출, 감정 분석과 분류 등의 간단한 Python API를 제공합니다. 기본 분석기만으로 필요한 도메인과 언어를 다루는지, 모델 확장이 필요한지 확인합니다. |
| Stanford CoreNLP | 토큰, 품사, 개체명, 구문 구조와 감정 등의 언어 주석을 생성하는 Java 파이프라인입니다. 필요한 언어 모델과 실행 자원을 준비합니다. |
| spaCy | 토큰화, 품사, 개체명과 의존 구문 등의 정보를 이용하는 텍스트 처리 파이프라인을 제공합니다. 감정 분석에 맞는 구성과 데이터 준비가 필요합니다. |
라이브러리의 기능 범위와 특정 감정 모델의 정확도는 별도로 평가합니다. 기본 API의 간편함, 필요한 사용자 정의 범위와 처리량을 함께 비교합니다.
평가할 어려움
| 항목 | 확인할 사례 |
|---|---|
| 반어와 비꼼 | 표면상 긍정 단어로 부정적 뜻을 표현한 문장 |
| 문맥에 따른 극성 | 같은 단어가 대상이나 주변 문장에 따라 반대 의미를 갖는 경우 |
| 언어와 문화 | 같은 표현 강도나 관용구를 언어별로 다르게 해석하는 경우 |
| 전처리 | 수작업 규칙이 부정어와 문장부호 같은 신호를 제거하는 경우 |
| 데이터 의존성 | 정답 자료가 부족하거나 특정 집단과 주제에 치우친 경우 |
| 계산 비용 | 모델 학습과 추론에 필요한 자원 및 운영 경험 |
| 변화 적응 | 새로운 표현과 업무 용어를 규칙이나 모델에 반영해야 하는 경우 |
| 도구 범위 | 필요한 분석을 기본 기능으로 처리할 수 없어 확장이 필요한 경우 |
LLM을 사용한 분류
GPT-4나 Llama 계열 같은 LLM은 문장 전체의 문맥, 비문자적 표현과 다국어 텍스트를 해석하는 감정 분석에 사용할 수 있습니다. 사용할 언어와 실제 업무 자료로 모델을 비교하고, 분류 기준을 프롬프트에 명시한 뒤 시험 사례를 통해 지시문을 조정합니다.
출력은 다음과 같이 설계할 수 있습니다.
- 극성 분류는 negative, neutral, positive 같은 범주를 선택합니다.
- 정서 분류는 happiness, sadness, anger처럼 정해 둔 정서 범주를 선택합니다.
- 수치 분류는 지정한 범위 안의 점수로 감정의 방향이나 강도를 표현합니다. 범위와 양 끝의 의미를 정해야 합니다.
모델을 바꿔 비교할 수 있는 구성, 명확한 지시문과 반복적인 프롬프트 평가가 필요합니다. 정서 레이블이나 점수는 정의한 분류 기준에 따른 추정 결과입니다.
Pipeline Builder의 Use LLM
Use LLM 노드는 표의 입력 열을 모델에 보내고 출력 열을 만드는 방식으로 기존 파이프라인에 연결합니다. 플랫폼 관리자가 custom workflow용 AIP 기능 권한을 부여해야 합니다.
- 입력 데이터셋 노드를 선택하고 Use LLM을 엽니다.
- 사용할 모델을 선택합니다. 플랫폼에서 제공하는 모델 또는 등록한 모델을 사용할 수 있습니다.
- 기본 템플릿을 선택합니다. Classification, Summarization, Translation, Sentiment analysis와 Entity extraction의 다섯 유형이 있으며 Empty prompt로 직접 작성할 수도 있습니다.
- Sentiment analysis에서는 점수 범위를 지정합니다. 가령 0을 가장 부정적, 5를 가장 긍정적으로 해석하는 0~5 척도를 구성합니다. 긍정/중립/부정 레이블이 필요하면 Classification에서 범주와 입력 열을 지정합니다.
- 프롬프트와 Output type을 정합니다. Struct는 지정한 스키마로 엄격하게 파싱하며 구조가 맞지 않으면 오류가 발생합니다. Include errors를 선택하면 원래 결과와 오류 문자열을 담은 struct로 출력합니다.
- 일부 입력을 Trial run에서 실행합니다. Input table의 행을 선택하여 Use rows for trial run으로 가져오거나 사례를 직접 추가할 수 있습니다. 원시 프롬프트와 응답을 확인하면서 기준을 다듬습니다.
- 결과가 업무 기준에 맞으면 노드를 적용하고 후속 변환과 출력에 연결합니다. 전체 데이터 처리 전에는 호출량, 모델의 rate limit과 오류 처리 방식을 함께 정합니다.
일부 행의 시험은 전체 데이터셋을 처리하기 전에 프롬프트를 조정하는 데 사용합니다. 모델 호출과 실행 자원은 실제 사용량을 발생시키므로 캐시와 동시성 설정도 검토합니다.
Build with AIP의 시작 구성
Build with AIP의 Pipeline Builder 감정 분석 starter pack은 positive, negative, neutral 레이블을 지정하는 흐름을 제공합니다. 사용자 입력으로 프롬프트를 생성하고 실제 입력으로 LLM을 시험할 수 있으며, 처리율 제한과 오류 처리를 포함한 파이프라인 구성을 제공합니다.
고객 피드백에서는 개선할 제품과 서비스를 찾고, 조직 피드백에서는 개선 과제를 정리할 수 있습니다. 제품 리뷰를 분류하여 반복되는 문제를 찾거나 콘텐츠 관리에서 검토할 표현을 추리는 데도 사용할 수 있습니다. 분류 결과를 고객 대응, 조직 운영이나 콘텐츠 처리 결정에 연결할 때는 운영 앱의 검토와 실행 조건을 함께 설계합니다.