DEVOCEAN

에필로그

LLM기반 Agent(LLM Agent 또는 Agent(LLM))는 LLM(Large Language Model)과 보다 복잡한 작업을 수행할 수 있는 LLM 어플리케이션들을(Chat Application, Funtion Call, RAG, ...) 모두 포함합니다. 생성형 AI 기술기반 챗봇 시장은 10년 이내에 1조 달러(1,390조 원) 규모로 커질 것이라는 해외 시장 전망이 있습니다. 24년5월 구글과 Open AI, 그리고 24년6월 애플이 각각 제시한 AI Agent 시나리오는 향후 Agent 서비스의 가능성을 예시를 통해 보여주었습니다. 과거에는 고객 상담에 챗봇을 적용하여 사전에 정해진 답변만 제공하는 등 Rule 기반 단순 기능이었다면, 앞으로는 챗봇이 보다 지능화되어 고객의 메시지를 요약하고, 일정을 자동으로 등록하거나, 고객의 감정과 취향에 적합한 음악과 영화를 자동 추천하는 등 복합 기능을 제공하는 즉, 사람 대신 각종 업무를 대신하는 AI Agent로 발전해 나갈 것으로 보입니다. 따라서, 메일 Agent, 스케쥴 Agent, 뮤직 Agent, 영화 Agent 등 다양한 도메인 특화 기능의 Multi-Agent들이 통합되어 토털 개인화 서비스(PAA, Personal AI Assistant)를 제공할 날도 멀지 않아 보입니다.

그렇다면, 우리는 이러한 기술과 비지니스의 진화 방향에서 다양한 Agent들이 보다 고도화된 품질의 서비스를 제공하기 위해서 운영 관점에서 어떻게 대비해야 할까요?

24년2월 에이닷에서는 원하는 음악을 쉽게 찾고 플레이리스트를 편하게 편집할 수 있는 에이닷 뮤직 Agent를 출시하였습니다. 우리는 이 서비스를 고객들이 어떻게 쓰고 있는 지, Agent의 LLM은 어떤 응답과 추천을 하는지 모니터링 해보기로 했습니다. 24년3월부터 7월 현재까지, 우리는 뮤직 Agent(도메인 특화 fine-tuned LLM) 서비스의 런칭 이후로 LLM 발화 운영 업무를 중심으로 새로운 운영 체계 수립 및 프롬프팅 엔지니어링을 실무 현장에서 적용했던 사례들을 공유하고자 합니다.

결론을 먼저 말씀드리면 에이닷 운영기획 서비스운영팀에서는 새로운 운영체계와 운영 LLM을 도입하여 운영 리소스를 50% 감축하면서, 동시에 발화 작업량은 3배로 증대시켰으며, 동시에 뮤직 Agent 서비스의 fail response(오응답) 품질을 런칭 3개월 만에 6% 수준으로 약4배 감소시켰습니다. 우리가 앞서 경험했던 사례들이 앞으로 여러분들의 다양한 AI Agent(LLM) 구축 및 운영에 조금이라도 도움이 되시길 바랍니다.

그림 1. LLM을 활용한 Agent 운영 효율화의 결과

대상 서비스

24년3월 에이닷에서 원하는 음악을 쉽게 찾고 플레이리스트를 편하게 편집할 수 있는 뮤직 Agent 서비스를 출시하였습니다.

에이닷 뮤직 Agent는 사용자가 텍스트 또는 음성으로 대화하듯 쉽게 음악을 찾을 수 있고, 음악을 고르기 귀찮다면 내 취향에 딱 맞게 플레이리스트를 편집할 수 있습니다.

사용자가 선호하는 가수나 장르를 기반으로 맞춤형 플레이 리스트를 만들고 편집할 수 있는 차별화된 기능의 장점이 있습니다.

예를 들어, 다음과 같이 쉽게 음악을 찾을 수 있습니다.

• 예: BTS 노래중 발라드만 들려줘. 아이유 노래 중 빠른 노래 틀어줘. 내 취향에 맞는 노래 틀어줘. 음악 아무거나 틀어줘.

또한, 예를 들어, 다음과 같이 쉽게 플레이리스트를 편집할 수 있습니다.

• 예: 운동하기 좋은 걸 그룹 노래 들려줘. 발라드와 재즈 더해줘. 힙합은 빼줘. 뉴진스랑 아일릿 노래 섞어줘.

이렇게 사용자의 자유 발화 (텍스트 또는 음성)가 입력되면 뮤직 Agent의 LLM은 뮤직 도메인에 대한 전문적인 검색과 추천의 결과로 응답합니다. 사용자의 자유 발화 형태는 단문 형태의 단독 발화, 복문 형태의 복합 발화, 다양한 조건들이 포함된 복합 중첩 발화, 그리고 문장이 연쇄적으로 이어지는 멀티 턴 발화 등이 있습니다. 자유 발화의 문장 및 어조는 평서문, 명령문, 의문문, 간투체, 간결체, 만연체 등이 있습니다. 자유 발화의 단어 형태는 전문 용어, 신조어, 약어, 은어, 중의어, 다의어 등이 있습니다.

사람과 Agent간 대화가 마치 사람과 사람의 대화처럼 자연스럽게 이어지면서 올바른 답변을 제공하기 위해서는 Agent가 사람만큼 많은 data를 학습해야 할 것 입니다. 하지만 사람은 신조어, 약어, 은어 등 새로운 단어를 지속적으로 만들어 내며, Agent는 학습하지 않은 새로운 단어나 문장을 모두 정확한 의미로 답변하지 못합니다.

우리는 뮤직 Agent 서비스를 실제 고객들이 어떻게 쓰고 있는 지, Agent의 LLM은 어떤 응답과 추천을 하는지 Log Data를 모니터링하여 운영해보기로 했습니다.

만들게 된 이유

예상치 못한 사용자 발화의 다양성: 서비스 런칭 직후, Log data를 수집, 분석해보니, 사용자 발화는 기획팀, 개발팀, QA팀, 운영팀, 어느 팀에서도 전혀 예상하지 못한 다양한 사용자 발화들이 유입되었습니다. Log data의 사용자 발화, LLM 응답 발화, 추천 결과 등은 마치 Success Response(성공 응답 발화)처럼 보였습니다. 하지만, 놀랍게도 의미론적 내용을 보면 Fail Response(실패 응답 발화)인 경우가 적지 않았습니다. 사용자 의도와 의미에 적합하게 응답하지 못한 LLM 결과는 좋지 않은 사용자 경험을 주고 있었습니다.

대표적인 예시들은 아래와 같습니다.

환각 실패 발화 (Hallucination Fail): 학습하지 못한 단어나 문장을 다른 의미로 환각하는 경우가 서비스 런칭 초기에 있었습니다.

• 예1: (사용자) 이승기 삭제 → (LLM) 이승기 노래를 삭제하겠습니다. (추천 결과) 삭제라는 노래를 못찾음.

• 예2: (사용자) 선업튀 → (LLM) 선업의 노래를 찾겠습니다. (추천 결과) 선재업고튀어(선업튀) OST 못찾음.

• 예3: (사용자) 이세돌 노래 → (LLM) 이세돌님의 노래를 찾아 볼게요. (추천 결과) 이 세계 아이돌(이세돌) 노래 못찾음.

부분 실패 발화 (Partial Fail) : 서비스 런칭 초기에 추천 결과의 일부분에서 fail이 포함된 경우입니다.

• 예: (사용자) 아이유 최신 노래 → (LLM) 찾아볼께요. (추천 결과) 아이유 전체 노래 찾음. 오래된 노래도 일부 포함.

숨겨진 실패 발화 (Hidden Fail) : 추천 결과의 내용을 뮤직 도메인 전문가의 확인이 필요한 fail 사례입니다.

• 예: (사용자) 벤슨분 노래 틀어줘 → (LLM) 벤슨 노래를 찾겠습니다. (추천 결과) 벤슨 노래 추천. ~분을 의존명사 사람으로 잘못 인식함.

모호한 실패 발화 (Ambiguous Fail): 기준 정립에 따라 fail or success가 모호한 사례입니다.

• 예: (사용자) 유명한 랩 틀어줘 → (LLM) 유명한 랩을 틀어 드릴께요. (추천 결과) 오래 된 랩, 차트에 오랜 기간 있지 않았던 랩도 추천. 유명하다는 기준 정립이 모호.

우리는 이러한 실패 발화들을 분류해가며 새로운 운영 지표들로 분류 기준을 정의해 나갔습니다.

문제

NLU 에서 LLM 으로 Paradigm 변화: 과거 True/False가 명확한 Rule 기반 NLU(Natural Language Understanding) 대화형 어플리케이션과 달리, 생성형 AI 기술기반 LLM 대화형 어플리케이션은 학습한 Data에서 Text를 생성하므로 True/False가 명확한 것과 그렇지 않은 부분까지도 답변할 수 있습니다. 따라서, 기존의 이분법적인 Rule 기반 NLU 운영 방식으로는 새로운 생성형 AI 기반 LLM 운영 방식을 적용할 수 없었으며, 새로운 운영 체계에 대한 인식의 전환이 필요하게 되었습니다.

• LLM의 응답 특징: 그럴 듯 한 답변을 하며, 동일한 질문도 매번 조금씩 다른 답변을 하며, Data를 많이 학습하면 할수록 답변 품질이 좋아진다는 특징이 있습니다. 또한, LLM은 학습하지 않은 Data (Untrained Data or Unseen Data)가 포함된 사용자 발화가 유입되면 엉뚱하거나 아니면 그럴듯한 헛응답(Hallucination)으로 답변하기도 합니다.

Semantic Search(의미론적 검색) 중요성의 대두: Semantic Search이란 발화의 단어와 문장 그대로 일치하는 콘텐츠가 아니라, 의미와 일치하는 콘텐츠를 반환합니다. 위에서 예시들을 살펴본 바와 같이, LLM의 그럴 듯 한 답변은 의미론적 내용과 일치하지 않을 수 있습니다. 생성형 AI 기술기반 LLM의 그럴듯한 답변과 추천 결과는 의미론적 일치와 의미론적 불일치의 구분이 서비스 품질을 좌우하는 중요한 요소로 부각되게 하였습니다.

• 사전 semantic search 검증: 런칭 이전에 사용자 발화를 모두 예상하여 품질 검증 후, 서비스를 런칭하기는 현실적으로 불가능합니다. 단, 빈도가 많을 것으로 예상하는 수 백개의 대표 발화(TC, Test Case)로 사전 검증할 수는 있지만 실제 서비스를 감당하기에는 그 수량과 내용에서 현실적인 한계가 있을 수 밖에 없습니다.

• 사후 semantic search 검증: 런칭 이후에 실제 사용자 자유 발화는 예상하지 못한 다양한 문장 유형들이 지속 발생되고 유입됩니다. LLM이 학습하지 않은 다양한 발화 유형이 신규 생성되므로 LLM의 추가 학습을 위해 신속하게 추출, 분석 및 제공되어야 합니다.

• 도메인 특성별 약어와 신조어의 지속 발생: 뮤직 도메인의 경우, 매달 신인 가수, 신규 노래가 출시되고, 곧이어 약어(줄임말)과 신조어, 은어 등이 생성되어 발화로 유입됩니다. (ex. 투바투(투모로우 바이 투게더) 등) 미디어 도메인의 경우에도 매월 새로운 드라마와 영화가 업데이트되고, 마찬가지로 약어와 신조어 등이 유입됩니다. (ex. 선업튀(선재업고튀어) 등)

업무 체계 전환의 필요성:

• 기존 품질 검증의 한계: 런칭 이전의 품질 검증 업무에서는 Application의 기능적 검증은 가능했으나, LLM 발화와 추천결과의 semantic search의 검증은 새로운 영역이며, 이를 추가하기 위해서는 별도의 도메인별 운영 인력들과 수작업이 필요하게 됩니다.

• 기존 운영의 한계: 런칭 이후 운영 업무에서는 semantic search은 가능하지만 많은 노동력과 시간이 투입되는 수작업입니다. Log data에서 하루 수 천에서 수 만 건의 사용자 발화, LLM 응답을 확인하는 것은 사람의 단순 반복의 수작업이며, 물리적 시간의 한계 등으로 모든 발화를 확인하기 불가능할 뿐만 아니라, 각자 개인의 역량에 따른 판단 결과의 편차가 발생하기도 합니다.

• 새로운 운영 체계의 필요성: Semantic search를 최종 판단하는 일은 휴먼 피드백의 수작업이 필요합니다. 많은 인력 비용과 시간이 투입되는 반복적인 수작업을 자동화할 수 있는 방안이 필요합니다.

우리는 문제 해결을 위한 솔루션으로 새로운 운영 체계에서 범용 LLM을 서비스 운영 업무에 도입하여, semantic search에 투입되는 노동력과 시간을 크게 절감시키고, 동시에 고객이 원하는 추천 결과를 향상시키는 것에 가치를 두고 문제를 해결하고자 했습니다.

가설

• LLM은 항상 그럴 듯 한 답변으로 응답한다. → 발화 패턴을 LLM에 학습시켜서 운영에 접목할 수 있지 않을까?

• LLM은 동일한 질문도 매번 조금씩 다른 응답으로 답변한다. → 운영 지표(Operation Metric)를 만들어서 지표별 그룹으로 분류할 수 있지 않을까?

• LLM은 Data를 많이 학습할 수록 응답 품질이 점점 좋아진다. → 운영 지표로 분류한 발화 패턴을 다시 개발팀에 피드백으로 전달하고 LLM 모델을 재학습 시키면 되지 않을까?

• 하루에 수천, 수만 건의 발화 리스트를 한 줄, 한 줄 보고 운영 지표별로 분류하는 반복적 수작업은 불가능한데... → 범용 LLM으로 자동 분류할 수 있지 않을까?

• 운영 업무의 50% 이상 자동화가 가능할까? → 자동화 효과가 큰 부분과 적은 부분으로 구분할 수 있지 않을까?

• 이상적으로 100% 까지 완전 자동화가 가능할까? → 100% 자동화가 100% 정확성을 담보할까? 2차 휴먼 필터링과 휴먼 피드백이 전혀 필요없을까?

시행 착오

• 24년 2월 서비스 런칭: Agent(도메인 특화 fine tuned LLM) 서비스 운영은 처음인데, 어떡하지? 참고할 국내외 사이트도 없네.

• 24년 3월, 4월: Agent(LLM) 서비스에서 모든 사용자 유입 발화의 Semantic search를 위해 일단, 많은 사람들이 수작업으로 추출, 분석해 보자.

• 24년 5월, 6월: 운영 프로세스에서 발화 패턴 분류의 반복 작업은 범용 LLM (ex. ChatGPT)을 도입하여 자동화해 보자.

• 24년 7월 현재: 운영 지표(OM, Operation Metrics)를 계속 업데이트하고, 운영 LLM의 Prompt Templates을 매주 지속적으로 업데이트하자. 운영 프로세스를 보다 효율화하자.

그림 2. ASOP(AI Agent(LLM) Service Operation Process)

우리는 시행착오를 거치면서 문제 해결을 위한 솔루션으로 사전 4단계와 사후 4단계를 운영 프로세스를 수립하였습니다. 전체 프로세스 내용은 아래와 같습니다.

우리는 전체 운영 프로세스를 ASOP(AI Agent(LLM) Service Operation Process) 이름으로 명명합니다.

운영의 데이터 소스는 실제 서비스 중인 Log data 를 기반으로 하며, 실제 사용자 발화, LLM 응답 발화 및 추천 결과 등이 핵심 운영 데이터 항목이 됩니다. 운영의 핵심 업무는 Log data 수집 및 분석을 기반으로 운영 지표의 기준에 따라 fail과 success를 자동 및 수동 분류하는 것입니다. 운영 솔루션의 최종 목표는 운영팀에서 실제 서비스 Log data에서 fail 지표를 분류하여 개발팀에 제공하여 Example 학습 Data로 Agent LLM Model의 fine-tuning 을 한 후, Agent(도메인 특화 fine tuned LLM) 서비스의 품질을 향상시키는 것 입니다. 따라서, 기존에 학습되지 않은 새로운 단어나 문장을 Agent LLM Model 이 재학습 및 fine-tuning 을 하게 됨으로써 보다 더 정확한 답변과 추천 검색을 제공하게 됩니다.

• 런칭 이전 사전 운영(Prior Operation Process) 의 순서는 1단계 기획팀으로부터 대표발화 (TC, Test Case) 수신, 2단계 예상 발화 생성, 3단계 개발팀에서 Agent LLM 모델의 지속 학습, 4단계 QA 및 런칭 순서입니다.

• 런칭 이후 사후 운영(Post Operation Process) 의 순서는 1단계 운영지표 수립, 2단계 서비스 log data 수집 및 LLM의 분류, 3단계 휴먼 필터링, 4단계 Agent LLM 모델의 fine-tuing 순서로 진행하였습니다.

• 사전 운영 단계에서는 사용자 예상 발화 자동 생성 (text generation task, 텍스트 생성 작업)을 핵심 업무로 합니다.

• 사후 운영 단계에서는 사용자 실제 발화 자동 분류 (custom text classification task, 사용자 정의 텍스트 분류 작업)을 핵심 업무로 합니다.

  LLM은 크게 2가지로 분류 및 정의합니다.

• 뮤직 Agent의 LLM은 뮤직 도메인 특화 LLM으로 정의합니다. (ex. 도메인 특화 Fine-tuned LLM for Service)

• 운영에서 사용할 LLM은 범용 도메인 LLM으로 정의합니다. (ex. ChatGPT for Operation)

• 자동화란 범용 LLM을 통해 운영 지표에 따른 사용자 발화를 1차 자동 분류하는 작업을 말합니다.

• 수동화란 자동화를 통해 1차 자동 분류된 발화 및 지표를 fail 부분만 2차로 휴먼 필터링 및 휴먼 피드백을 통해 재검증하는 작업을 말합니다.

본 회차에서는 사후 운영(Post Operation Process) 단계의 사례를 설명합니다. 다음 회차에서는 사전 운영 단계의 블로그를 게시할 예정입니다.

사후 운영(Post Operation Process)의 4단계 아래와 같습니다.

Step 1. 운영 지표 수립

사후 운영의 첫번째 단계는 런칭 직전에 운영 지표(OM, Operation Metrics) 를 수립하는 것입니다.

운영 지표란 실제 서비스 중에 사용자 발화 유입 시, 발화 패턴의 분류 기준을 의미합니다.

초기 단계에서는 런칭 이전에 기획팀의 시나리오와 대표 예상 발화를 보고, 수작업으로 운영 지표를 수립합니다.

런칭 이후에 사용자 발화 유형을 보고, 지표를 추가하거나, 향후 기능이 추가되면 지표를 추가 또는 수정할 수 있습니다.

따라서, 운영 지표는 초기 수립 이후에 고정 불변하는 것이 아니며, 추가 세분화 되거나, 수정 변경이 될 수 있습니다.

• 성공 지표(success metrics)는 사용자 발화 질의에 대하여 Agent(LLM) 응답 및 추천 결과가 의미론적 일치(semantic match) 하는 정상 답변 지표입니다.

• 실패 지표(fail metrics)는 성공 지표와 반대 경우로 의미론적 오류(semantic error) 또는 검색 실패(search fail) 지표입니다.

• 기타 지표(other metrics)는 기기 제어 발화, 해당 없음 발화, 오타 발화 등에 해당하는 지표입니다.

Step 2. 발화 Log Data 수집, LLM의 자동 분류 (운영 업무에 LLM 적용 - 자동화)

서비스 런칭 이후, 사용자 실제 발화 운영은 Log data 를 기준으로 후처리 대응으로 Daily or Weekly로 진행하게 됩니다.

Log data 수집 및 전처리 작업과 LLM의 자동 분류를 위한 프롬프팅 작업으로 나뉩니다.

Log data는 csv 파일 형태로 다운로드 할 수 있으며, 많은 컬럼들 중, 실제 사용자 발화 컬럼, LLM 응답 컬럼, 추천 결과 컬럼 등이 발화 운영에 중요한 항목들입니다.

그림 3과 같이 LLM 프롬프팅 입력을 위하여 Q: 컬럼, A: 컬럼과 Metrics 컬럼을 추가합니다.

그림 3. 발화 Log Data 수집 및 전처리

뮤직 Agent 서비스의 LLM은 뮤직 도메인 특화 LLM (ex. Fine-tuned LLM for Service) 입니다. 다양한 사용자 질의에 대해 뮤직 도메인에 대한 전문적인 검색과 추천의 답변을 제공합니다.

하지만 실제 서비스에서 사용자 자유 발화는 정형화되어 있지 않으며, LLM이 학습되지 않은 data도 유입되는 것이 현실입니다.

운영팀에서 사용하는 LLM은 범용 도메인 LLM (ex. ChatGPT for Operation) 입니다. 단지, 분류 Task를 위해서, 즉, 운영 지표별 사용자 발화 패턴의 자동 분류를 위하여 범용 도메인 LLM을 사용합니다.

범용 도메인 LLM 을 사용한 자동 분류는 사용자 발화, 뮤직 Agent LLM의 답변 및 추천 결과 내용의 Log Data를 프롬프팅을 통해 few shot examples을 포함한 In context learning 방식으로 운영 지표별로 분류하도록 실행합니다.

그림 4와 같이 프롬프팅에서는 Input Context 의 Task description, Few shot examples 부분의 설명은 아래와 같습니다.

• Persona 부여 prompting (ex. 너는 뮤직 DJ 역할이야.)

• Context 문맥 설명 prompting (ex. 아래 예시와 같이 Q: 가수, 노래, A: success or fail 응답이야.)

• Few shot example 예시 prompting (ex. Q: 뉴진스 노래, A: search_success )

그림 4와 같이 Q: 질문과 A: 빈칸 형식으로 1,000 문장을 입력하고, 지시사항을 입력합니다.

• Instruction 지시사항 prompting (ex. 아래 문장들에서 A: 응답을 생성해줘)

그림 4의 우측 그림과 같이 A: 빈칸의 지시사항 문장에서 A: success or fail 의 답변을 범용 LLM (ex. ChatGPT)가 자동 분류해줍니다. 여기 프롬프트의 핵심은 Instruction 이전에 Context(문맥) 설명과 Few shot examples(예시)의 제공 품질과 양이 중요합니다. 문맥 설명과 예시 제공의 품질에 따라, 지시 사항에 대한 수행 결과의 차이가 크게 발생됩니다.

그림 4. LLM의 자동 분류를 위한 프롬프팅 예시 (custom text classification task, 사용자 정의 텍스트 분류 작업)

Step 3. 휴먼 필터링, 휴먼 피드백 (LLM이 Fail로 분류한 발화만 재검증 - 수작업 최소화)

범용 도메인 LLM(ex. ChatGPT)으로 1차 자동 분류 후, 휴먼 필터링과 휴먼 피드백으로 2차 분류 및 재검증을 수행합니다.

1차 LLM 자동 분류, 2차 휴먼 (수동) 분류의 더블 체크로 fail 지표의 정확성 향상을 담보하기 위함입니다.

Semantic Search(의미론적 검색) 은 최종적으로 사람의 의사결정이 필요하며, 이를 위해서는 도메인 전문 인력들의 수작업이 필요하며, 이러한 수작업은 많은 인력과 시간이 투입됩니다.

전체 100% Log Data를 범용 도메인 LLM으로 1차 자동 분류로 필터링하였으며, 그 중 6~10% 가량의 fail 항목만 수작업으로 2차 휴먼 필터링하게 되므로 수작업의 분량이 크게 줄어들게 되므로 투입 인력과 시간이 경감됩니다.

휴먼 필터링이란 fail 지표 항목만 다시 수작업으로 재확인하는 과정입니다.

휴먼 피드백이란 fail 지표 항목의 fail 원인을 찾아서 작성 및 표기하는 것을 말합니다.

그림 5와 같이 fail 항목들을 선별하여 작업합니다.

그림 5. LLM의 자동 분류 결과에서 Fail 운영지표 항목들만 다시 휴먼 필터링 재검증

Step 4. Agent(LLM) 모델 파인 튜닝 (운영팀에서 개발팀/기획팀으로 example 학습 data 제공 및 재학습)

위에서 휴먼 필터링과 휴먼 피드백 과정까지 거친 fail 지표 항목들은 Agent (도메인 특화 fine-tuned LLM)의 Model fine-tuing을 위한 example 학습 data 로 개발팀에 제공합니다.

그림 6과 같이 Log data 100%를 수작업하는 것이 아니라, 범용 LLM (ex.ChatGPT)의 자동 분류의 결과로 Fail 분류 결과만 수작업으로 재검증한 후, 최종 2번 검증된 Fail 결과를 개발팀에 제공하게 됩니다. 개발팀에서는 fail 지표 항목들 중, 뮤직 Agent(LLM)의 fine-tuning할 학습 data 를 선별하여 선택하게 됩니다. 기존 Model 에서 학습하지 못한 단어와 문장을 추가 학습하게 됨으로서 Model의 성능, 즉 Agent 서비스의 품질이 향상됩니다.

관건은 양질의 데이터를 모델이 주기적으로 재학습하여 모델의 품질을 지속 향상시키는 것입니다.

따라서, 운영팀에서는 실제 사용자 발화에서 모델이 학습하지 못한 단어, 문장을 찾아 개발팀에 주기적으로 제공해야 합니다.

또한, 개발팀에서는 양질의 데이터를 모델이 재학습하도록 주기적으로 또한 신속하게 업데이트해야 합니다.

전체적인 관점에서는 기획팀, 개발팀, 운영팀간 피드백 루프 구조에서 양질의 데이터가 신속하게 주기적으로 전달되고 학습되도록 각 팀에서 담당하는 역할들이 조화롭게 작동해야 합니다.

그림 6. ASOP 운영체계의 데이터 볼륨 및 흐름

많은 량의 data는 LLM 이 보고 분류하게 하고, Fail로 분류된 중요하고, 적은 량의 data는 사람이 분류하도록 합니다.

결론

에이닷 운영기획 서비스운영팀에서는 새로운 운영체계 ASOP(AI Agent(LLM) Service Operation Process) 하에서 실제 서비스 log data 수집 및 분석의 운영업무에 을 도입하여 정량적인 생산성 향상과 함께 정성적인 품질 향상의 효과를 동시에 달성 하였습니다. 우리는 정량적인 결과로 서비스 도메인별 3명에서 1.5명으로 50%의 리소스를 감축하면서도 작업량은 일 3천건에서 일 9천건 발화 건수로 3배 증가시켰으며, 동시에 정성적으로는 품질 일관성으로 정확성을 향상시켰습니다. 최종적으로 LLM 오응답(fail response) 품질을 런칭 3개월 만에 6% 수준으로 약4배 감소하는 품질 향상의 성과를 얻었습니다.

서비스 운영팀의 목표는 서비스를 운영하면서 사용자 경험을 개선시키고 고객 만족을 극대화하는 것입니다.

이것은 고객의 불편함을 해소하고, 편리함을 증대하여 서비스 품질을 고객이 기대하는 바, 그 이상으로 충족하는 것입니다.

따라서, 우리 서비스 운영팀은 서비스 Log data를 수집, 분석하여 실제 사용자의 불편함을 찾고,

이 불편함을 해소하기 위해 Agent(도메인 특화 fine-tuned LLM) Model fine-tuing을 위한 양질의 example 학습 data 를 개발팀과 기획팀에게 신속, 정확하게 제공하고 있습니다.

앞으로도 우리의 노력은 여기에 그치지 않고, 모델 성능 개선, 서비스 품질 개선, 사용자 경험 개선을 위해 ASOP(AI Agent(LLM) Service Operation Process) 운영 체계를 더욱 고도화할 예정입니다.

본 회차에서는 사후 운영(Post Operation Process) 단계의 사례를 살펴보고 설명을 드렸습니다.

다음 회차에서는 사전 운영(Prior Operation Process) 단계의 블로그 포스팅을 할 예정입니다.

여러분들의 실무 현장에서 조금이라도 도움이 되시길 바라며, 앞으로도 많은 관심을 부탁드립니다. 감사합니다.