의도 라우팅

들어오는 요청을 분류하고 각각을 최적의 핸들러, 즉 결정적 로직, 전문 LLM, 또는 사람에게 라우팅합니다.

모든 사용자 요청이 같은 종류의 핸들러를 필요로 하지는 않습니다. 어떤 것은 데이터베이스 조회로 답할 수 있습니다. 어떤 것은 도메인별 컨텍스트를 가진 LLM이 필요합니다. 어떤 것은 사람이 필요합니다. TypeSafe는 어느 핸들러를 호출할지 결정하는 빠르고 저렴한 분류기로서 이 모든 것 앞에 설 수 있습니다.

예: 고객 서비스 라우팅

고객 서비스 시스템을 구축한다고 상상해 봅시다. 메시지가 들어오면 올바른 핸들러로 라우팅해야 합니다. 모든 메시지를 값비싼 LLM을 통해 보내 어떤 종류의 요청인지 알아내는 대신, 먼저 분류하고 그에 따라 라우팅합니다.

%%{init: {"fontFamily": "Inter, sans-serif", "flowchart": {"rankSpacing": 35, "wrappingWidth": 300, "subGraphTitleMargin": {"top": 12, "bottom": 36}}}}%%
flowchart LR
    message["customer message"]

    subgraph req["TypeSafe evaluates questions<br/>in parallel"]
        direction TB
        intent["<b>Choice:</b> intent"]
        complexity["<b>Score:</b> complexity"]
        %% Invisible links stack the questions; they are answered in parallel.
        intent ~~~ complexity
    end

    message -- "one request<br/>message + 2 questions" --> req
    req -- "one response<br/>2 answers with<br/>confidence" --> confidence{"<b>intent confidence<br/>≥ 0.5?</b><br/>your code"}
    confidence -- "no" --> human["human agent"]
    confidence -- "yes" --> route{"<b>which intent?</b><br/>"}
    route -- "order_status" --> order["order lookup<br/>deterministic code"]
    route -- "product_question" --> product["product specialist LLM"]
    route -- "return_exchange" --> returns["returns specialist LLM"]
    route -- "complaint" --> escalate{"<b>complexity > 1<br/>or its confidence < 0.5?</b><br/>"}
    escalate -- "yes" --> human
    escalate -- "no" --> complaint["complaint resolution LLM"]

1단계: 의도와 복잡도 분류하기

{
  "intent": {
    "type": "choice",
    "instructions": "The primary intent of this customer message",
    "criteria": {
      "order_status": "Asking about an existing order",
      "product_question": "Asking about a product before buying",
      "return_exchange": "Wants to return or exchange something",
      "complaint": "Unhappy with experience, wants resolution"
    }
  },
  "complexity": {
    "type": "score",
    "instructions": "How complex is this request to resolve",
    "criteria": [
      "Simple lookup or standard procedure",
      "Requires some judgment or multi-step process",
      "Unusual situation, edge case, or escalation needed"
    ]
  }
}

2단계: 최적의 핸들러로 라우팅하기

routing.py

def route_ticket(ticket_id, response):
    intent = response.answers["intent"]
    complexity = response.answers["complexity"]

    if intent.confidence < 0.5:
        # If we don't have enough confidence to classify, route to a human agent
        return route_to_human_agent(ticket_id)

    if intent.choice == "order_status":
        handle_order_status(ticket_id)

    elif intent.choice == "product_question":
        handle_with_llm(ticket_id, PRODUCT_SPECIALIST)

    elif intent.choice == "return_exchange":
        handle_with_llm(ticket_id, RETURNS_SPECIALIST)

    elif intent.choice == "complaint":
        low_confidence = complexity.confidence < 0.5
        # A higher complexity.score leans toward the "escalation needed" end of the scale.
        if complexity.score > 1 or low_confidence:
            # Too complex for safe automation, or we're not sure about the complexity; route to a human.
            route_to_human_agent(ticket_id)
        else:
            handle_with_llm(ticket_id, COMPLAINT_RESOLUTION)

의도 하나는 LLM이 전혀 개입하지 않는 결정적 코드로 라우팅됩니다. 둘은 서로 다른 컨텍스트를 적재한 서로 다른 전문 LLM으로 라우팅됩니다. 하나는 복잡도 점수를 사용해 LLM과 사람 사이에서 결정합니다. TypeSafe는 이 분류를 단 한 번의 빠른 호출로 처리하며, 값비싼 자원은 실제로 그것이 필요한 요청에만 호출됩니다.

복잡도 점수에 대한 추가 신뢰도 확인에 주목하십시오. 신뢰도에서 논의한 것처럼, 낮은 신뢰도 점수의 의미를 시스템의 맥락과 결정의 위험도 안에서 고려하는 것은 항상 중요합니다.