DEVOCEAN

이번 에이닷 개편에서도 홈 에이전트의 기획을 수많은 기획자, 개발자분들과 함께 수행했습니다!

LLM 향으로 전환하면서 기존 기능을 포함하여 검색 기능을 도입하는 방향으로 프로덕트를 개선했는데요,

본 게시글은 제가 집중적으로 참여했던 에이닷 홈 에이전트 내 ‘음식점, 카페 추천’을 위주로 작성하였습니다.

1. Function Call이란?

1.1 Function Call 정의

이번 개편에서 <에이닷 홈 에이전트>는 function call이라는 방법을 채택하여 기획-개발되었습니다.

그렇다면 function call이란 무엇일까요?

Open AI에서 2023년 출시한, 함수 호출을 통해 내외부 API를 적극적으로 활용할 수 있는 방법론입니다.

• 참고 : Function call 관련 Open AI document

기존의 LLM은 사전 학습된 데이터를 기반으로 사용자에게 응답을 제공하기 때문에

직접적인 검색 기능을 활용한 LLM이 아닌 이상 hallucination을 방지할 수 없다는 어려움에 봉착해 있습니다.

논리적으로 생성된 응답을 제공하더라도 사실에 기반한 데이터가 아니라면

사용자에게는 다소 유용도가 떨어질 수 있다는 단점이 존재했는데요,

이런 점을 보완하기 위해 function call이라는 방법론으로 에이전트를 구현하게 된 것입니다!

아래 그림의 구조처럼 <1.사용자의 발화를 분석 → 2. 발화에 해당하는 function을 호출

→ 3. function과 연계된 API 호출하여 값 반환 → 4. 최종 응답 생성> 의 과정을 지나게 되는데요,

이렇게 구현한다면 기존에 학습된 데이터 뿐 아니라 실제 값을 가져오는 내외부 api를 활용할 수 있습니다.

즉, API를 호출해서 실존 데이터를 가져온다는 특장점이 있다는 것이죠.

음식점, 카페 추천의 경우 기존에 운영하고 있는 DB를 기반으로 추천 목록을 LLM에게 주면,

LLM은 사용자의 앞뒤 발화 맥락과 요청에 따라 스스로 판단하여 맛집을 추천합니다!

1.2 Function Call prompting

각 Function에 대한 정의, 그리고 Function에 속하는 parameter를 정의하고,

그렇게 분류 및 추출된 parameter를 기반으로 에이전트는 스스로 어떤 도구(tool)를 선택해

응답을 생성할지 결정하게 됩니다.

설명을 위해 위 open ai 문서에 나와 있는 사례를 간략히 설명드리겠습니다.

다음의 코드는 ‘get_delivery_date’라는 함수(function=tool)를 활용하고 있습니다.

사용자의 요청에 정확도 높은 응답을 낼 수 있도록 각 함수의 이름,정의, 파라미터, 시스템 메시지까지 전부 기획과 프롬프팅의 영역이 되는 것입니다.

(이 부분에 대해서는 개발자분들과도 많은 논의와 검토가 필요합니다.)

• function 명 : Get_delivery_date

• 해당 함수의 설명 : 함수의 정의 - LLM은 이것을 보고 사용자 요청을 처리하기 위한 도구(함수)를 선택하게 됨.

  • “Get the delivery date for a customer's order. Call this whenever you need to know the delivery date, for example when a customer asks 'Where is my package'.”

• 해당 함수가 보유한 parameter(properties) :

  • order_id

• 필수로 추출해야 하는 parameter(properties) : 함수 object 내에 정의되어 사용자 발화 속에서 추출해야 하는 parameter

  • order_id

• system message : LLM이 참고해야 하는 agent의 특성

• 사용자 요청 : agent가 수행해야 하는 사용자의 발화(요청)

  • "Hi, can you tell me the delivery date for my order?"

python
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_delivery_date",
            "description": "Get the delivery date for a customer's order. Call this whenever you need to know the delivery date, for example when a customer asks 'Where is my package'",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {
                        "type": "string",
                        "description": "The customer's order ID.",
                    },
                },
                "required": ["order_id"],
                "additionalProperties": False,
            },
        }
    }
]

messages = [
    {"role": "system", "content": "You are a helpful customer support assistant. Use the supplied tools to assist the user."},
    {"role": "user", "content": "Hi, can you tell me the delivery date for my order?"}
]

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=tools,
)

2. 에이닷 홈 에이전트에서 음식점, 카페 추천은…

기존의 에이닷은 single-turn, 즉 단건 by 단건으로 요청을 처리했기 때문에

대화가 이어지면서 사용자의 의도를 좁혀나가는 것이 불가능했다면

LLM향으로 전환 + function call 방법론을 채택하면서

사용자의 의도에 좀 더 부합하고, 맥락을 보며 추천할 수 있도록 설계 되었다고 볼 수 있습니다!

좀 더 사용자의 의도를 세밀하게 인식할 수 있게 된 것이죠.

음식점, 카페 추천의 경우 ‘location’(위치) 등 다양한 parameter를 정의하여

그것을 기반으로 사용자가 발화한 요청을 LLM이 스스로 분석합니다.

(실제로는 더 많은 parameter를 추출하여 분기합니다만,

보안을 위해 작성하지 않았습니다.)

1. 사용자 요청 : “성수동 맛집 추천해줘”

2. “location : 성수동” parameter 추출

3. 추출한 parameter를 통해 해당하는 function 및 비즈니스 api 호출

4. api에서 받아 온 값을 통해 최종 응답 생성

5. 사용자에게 최종 응답 제공 : “성수동 맛집에는 a,b,c가 있어요.”

3. 무수히 지난했던 fine-tuning과 수정 개발

3.1 function 구현할 때 어려웠던 점

이번 구현을 위해 정말 많은 분들이 다양한 이슈를 대응했는데요,

두 가지 영역으로 나눠서 말씀드릴 수 있습니다.

첫번째는 function selection 성능을 위한 프롬프팅을 여러 가지를 시도해봤다는 점이고,

두번째는 에이전트의 전반적인 최종 응답 생성 성능의 고도화을 위해 fine-tuning을 진행했다는 점입니다.

좀 더 설명을 드리자면 제가 지금 논하고 있는 음식점, 카페 추천도 정보를 요청하는 발화이고

‘일정을 등록해줘’, ‘날씨 알려줘’, ‘지하철 혼잡도 알려줘’ 등의 기존 기능들 모두

일반적으로 흘러가는 보편적인 내용의 대화를 수행하는 것보다는

사용자의 요청을 기반으로 편의성 있는 정보를 제공하기 위해 만들어져 있는 요청성 발화에 가깝기 때문에

보편적인 대화의 흐름이나 논리와는 거리가 있는 양상의 대화를 하게 됩니다.

그래서 사전 학습(pre-trained)된 LLM 모델에게 요청성 대화 내용 위주의 학습 데이터를

Fine-tuning 시키면 시킬수록, LLM의 추론 및 생성 퍼포먼스에서

side-effect이 발생할 가능성도 계속해서 배제할 수 없는 거죠!

3.2 상세 예시

앞선 설명에서, LLM에게 각 function에 대한 정보를 주고, 그 정보와 사용자 요청을 읽어

LLM의 판단으로 처리하게 되는 것이 기본 로직이라고 언급을 드렸습니다.

이 과정 속에서 다음과 같은 사례를 비롯한 여러 이슈들이 학습 과정 중에 발생했습니다.

저희 Agent의 경우, 실제로 유사도가 높은 여러 기능들을 수행할 수 있습니다.

이것은 편리성 제공 측면에서 장점이기도 하지만, 구현에 있어 더 많은 공수를 들이게 될 수 있습니다.

예를 들면, 서로 다른 기능들에 대하여 같은 이름 혹은 유사한 이름의 parameter가 있을 때

두 function의 정의가 다르더라도 구분하여 판단함에 있어 혼동의 가능성이 있어

이를 위해 프롬프팅을 바꾸고 테스트를 하면서 지속적인 개선과 학습을 진행했습니다.

이 외에도 LLM과 비즈니스에서 필요한 api를 연동하기 위해

정말 많은 개발자분들이 큰 수고를 해주셔야 했고요,

그 과정 속에서 생겨나는 크고 작은 이슈들을 기획자-개발자-QA 파트의 모든 분들이 함께 들여다보며

완성도를 높이는 작업을 진행했습니다.

지난 과정을 회고하며..

LLM 기반 Agent를 구현하면서 NLU 기반의 Rule-based chatbot은 정말 다르다는 것을 여실히 느꼈습니다.

일전에 저는 어르신 돌봄콜 기획에 일부 참여했던 경험이 있었는데요,

발생할 수 있는 여러 시나리오를 학습 데이터로 만들어 예상 가능한 범위의 발화를 수행할 수 있도록 구축하는 것과

기존에 지니고 있는 많은 기능들을 대응하면서 각각의 성능을 해치지 않도록 설계하는 것은

또 다양한 검증과 시행착오를 겪어야만 한다는 것을 깨달을 수 있었습니다.

앞으로는 더욱 더 agent에 대한 구축 범위도 넓어지고, 영향도도 커질 것으로 예상되는데

이에 따라 이번 프로젝트에서 느꼈던 부분들을 보완할 수 있도록

기획과 디자인, 개발 전반적으로 배워나가야할 부분이 많을 것 같습니다!