6.3.4.2 필수 파라미터(Required Parameters) 환각 완화를 위한 스키마 설계

도구 호출(Tool Calling) 메커니즘을 파이프라인에 적용할 때 엔지니어들이 가장 빈번하게 범하는 실수는, 기존 관계형 데이터베이스(RDB) 테이블을 설계하던 습관대로 스키마의 required (필수) 파라미터를 남발하는 것이다. 이러한 경직된 설계는 역설적이게도 가장 악질적인 형태의 ’사실적 환각(Factual Hallucination)’을 강제로 유발하는 방아쇠가 된다.

1. 강압적인 스키마가 낳는 ‘창조적 거짓말’

예를 들어, 사용자 문의 글에서 정보를 추출하는 create_ticket(name: string, phone: string) 이라는 도구를 만들고 두 파라미터를 모두 필수(required)로 묶었다고 가정해 보자.

만약 사용자가 “제 이름은 홍길동인데, 결제가 안 됩니다“라고만 발화하여 텍스트 내에 전화번호가 존재하지 않는 경우 모델은 심각한 딜레마에 빠진다.

함수 호출을 포기하고 자연어로 “전화번호가 없습니다“라고 대답할 것인가? (구조적 실패)
어떻게든 함수 시그니처를 맞추기 위해 파라미터를 채워 넣을 것인가?

도구 호출로 강하게 튜닝된 모델일수록 후자를 선택한다. 모델은 강제된 스키마 규칙을 어기지 않기 위해 텍스트에 없는 전화번호(예: 010-0000-0000 혹은 임의의 난수 번호)를 스스로 지어내어(Fabricate) 파라미터 슬롯에 강제로 쑤셔 넣는다. 엔지니어가 스키마 무결성(Structural Integrity)을 얻으려다 데이터의 진실성(Truthfulness)을 잃어버리는 순간이다.

2. 환각 완화를 위한 오라클 스키마 설계 패턴

이러한 어처구니없는 환각을 방어하기 위해, 결정론적 오라클 설계자는 모델에 ’합법적인 도피처(Escape Hatch)’를 뚫어주는 정교한 스키마 설계 패턴을 적용해야 한다.

2.1 명시적 Null 허용과 방어적 설명(Description)

가장 근본적인 해결책은 타입(Type) 선언에 null을 단일 옵션으로 허용해 주는 것이다. 그리고 파라미터의 description (설명) 필드에 강력한 제약 조건을 자연어로 서술한다.

{
  "name": "phone",
  "type": ["string", "null"],
  "description": "사용자의 전화번호. 발화 텍스트 문맥상에서 전화번호를 명확히 찾을 수 없는 경우, 절대로 추론하거나 지어내지 말고 반드시 null을 반환하라."
}

이 속성은 파서의 관점에서는 여전히 ’필수 항목(Required Key)’으로 존재하여 KeyError를 막아 주면서도, LLM에게는 거짓말을 하지 않아도 스키마 규칙을 준수할 수 있는 합법적 탈출구가 된다.

2.2 선행 추론(Reasoning First) 파라미터의 배치

더욱 강력한 패턴은 도구의 첫 번째 파라미터로 데이터가 아닌 ’생각의 과정(Chain of Thought)’을 강제하는 속성을 배치하는 것이다.

{
  "properties": {
    "extraction_reasoning": {
      "type": "string",
      "description": "본격적인 데이터를 추출하기 전, 제공된 텍스트에서 이름과 전화번호가 존재하는지 단계별로 분석한 과정."
    },
    "name": { "type": ["string", "null"] },
    "phone": { "type": ["string", "null"] }
  },
  "required": ["extraction_reasoning", "name", "phone"]
}

LLM의 출력 토큰은 한 번 생성되면 이전으로 되돌릴 수 없는 단방향(Autoregressive) 특성을 갖는다. 만약 phone이 스키마의 맨 처음에 등장한다면 모델은 즉흥적으로 값을 채워버릴 위험이 크지만, extraction_reasoning 필드를 먼저 생성하게 만들면 “텍스트를 분석해 본 결과 전화번호에 대한 언급은 없다“라는 문장을 스스로 토큰화(Tokenize)하면서 컨텍스트를 확보하게 된다. 이후 다음 필드인 phone을 생성할 때 앞서 자신이 뱉은 문맥에 논리적으로 지배당하므로, 아무런 망설임 없이 확정적인 null을 뱉어낼 수 있다.

결론적으로, 도구 호출에서 완벽한 데이터 정합성을 얻으려면, 백엔드 데이터베이스의 물리적 타입 제약 모델과 LLM의 인지적(Cognitive) 통제 모델을 분리하여 더욱 고차원적이고 심리학적인 스키마 설계를 접목해야 한다.