• 모든 사용자의 요청은 질의 분류 → 데이터조회 → 응답의 흐름으로 처리

  • 먼저, 사용자의 자연어 메시지를 의도(Intent) 로 분류

    image.png

    • get_my_orders: 사용자의 주문 내역 조회
    • get_policy: 특정 api에 대한 질문이 아닌 환불/배송/교환 정책 등 비구조화 정보 질의 응답
    • get_my_profile: 사용자의 회원정보 조회

  • get_my_orders 처리 상세

    image.png

    • 기본 흐름 : 주문내역조회함수 → DB 조회 → LLM을 통한 응답 생성
    • 단계1. chatting 메시지 수신 및 요청 분기
      • llm을 통해 사용자의 chat 메시지의 의도를 분석하여 분기처리
    • 단계2. 사용자 인증
      • 해당 사용자의 주문만 조회하도록 jwt 토큰을 통해 로그인 사용자 식별
    • 단계3. api호출 및 LLM응답
      • 사전에 구현된 /orders/me api를 활용하여 사용자의 주문 내역 조회
      • api결과값을 llm에 호출하여 자연어 응답 생성
    • 단계4. 채팅로그 저장
      • Chat테이블에 메시지 request, 메시지 response 을 저장
    • 실습)주문 관련 질의 및 응답(/chats)
      • 토큰을 넣어 주문관련 질의 실습
      • 회원정보, 정책관련 질의시 분류 정상 확인

  • get_policy 처리 흐름

    image.png

    • 사내정책에 대한 Vector DB 문장 조회
      • 일반적으로 사내정책에 대한 “사용자의 질의”와 db에 저장된 “문장”은 일치하지 않음
      • 따라서, rdb에 저장하여 like와 같은 문자열 일치 조회를 하는 것은 적절치 않음
      • vectorDB, langchain등을 활용하면 문장간 유사도 검색 수행 가능
      • 가장 일치하는 몇개의 문장(top_k)를 조회하여 LLM에 전달
    • LLM은 넘겨 받은 컨텍스트를 기반으로 자연어 답변 생성
      • LLM은 사내 정책을 알지 못하므로 자체적으로 응답을 만들어내는것은 불가능
      • 그래서 vectorDB와 LLM을 사용하여 검색 및 응답생성을 하는 RAG패턴이 등장

  • get_my_profile 처리 흐름

    image.png

    • 회원정보 API(또는 DB) 조회
      • /members/me 등 내부 API 호출로 회원정보 확보
    • sLLM을 통한 응답 생성
      • 개인정보를 LLM으로 넘기는 것은 부적절할수 있으므로, 이 수업에서는 sLLM 도입
      • sLLM은 규모가 작은 모델을 로컬에 실행하는 것
        • sLLM은 보안에는 강점이 있지만 성능이 떨어질수 있는 고려
        • 다만, 서버가 넘겨주는 컨텍스트를 참고하여 문장을 만들기 때문에 응답의 퀄리티 유지