“Too Smart” Knowledge Base 문제: AI가 스스로에게 해가 될 정도로 너무 많이 알 때
Source: Dev.to
제가 크게 실수했어요. 작은 실수가 아니라요. “클라이언트가 금요일 밤 11시에 전화했다”는 식의 상황이었어요.
우리는 막 의료 클리닉의 예약 시스템을 배포했었습니다: 음성 AI, 고급 설정. 환자들이 전화를 걸면 AI가 예약을 잡아주고, 그게 전부였습니다. 적어도 원래 계획은 그랬죠.
클라이언트는 우리에게 모든 것을 넘겨줬습니다—15 년간의 의료 문서, 치료 프로토콜, 약물 상호작용 가이드, 의료 용어 데이터베이스, 보험 정책 문서, 그리고 10 000개가 넘는 FAQ 항목까지.
제 뛰어난 아이디어는 간단했습니다: 모두 넣어라. 맥락이 많을수록 AI가 더 똑똑해지겠죠?
틀렸어요. 아주 크게 틀렸어요.
실제로 일어난 일
| 날짜 | 통화 요약 |
|---|---|
| Day 1 | 환자가 딸의 열 때문에 진료 예약을 요청했습니다. AI는 소아 열 관리 프로토콜, 연령별 기준 및 의료 지침을 설명했습니다. 환자는 전화를 끊었습니다. |
| Day 2 | 다른 환자가 다음 주 화요일에 진료 예약을 요청했습니다. AI는 본인 부담금, 예방 치료 코드, 보험 조항 및 보장 규정에 대해 설명하기 시작했습니다. 환자는 “그냥 진료 예약만 원해요.”라고 화를 냈습니다. |
| Day 5 | 클라이언트가 전화를 걸었습니다: AI가 진료 예약 대신 의료 강의를 하고 있었습니다. 일주일 동안 통화량이 40 % 감소했습니다. |
그때 나는 내가 무슨 일을 했는지 깨달았습니다.
내가 만든 문제
AI가 전천후가 되었다.
- 나는 환자들이 예약 시 의료 질문을 할까 두려워서 의료 지식 베이스에 접근 권한을 부여했다.
- 나는 간단한 진리를 고려하지 않았다: 뭔가를 안다고 해서 말해야 하는 것은 아니다.
AI는 마치 파티 손님이 모든 가벼운 말을 TED 강연으로 바꾸는 것처럼 행동했다. 누군가 “밖이 덥다”고 말하면, 지난 50년간의 기후 데이터를 꺼내 들려준다. 당신은 논쟁하지 않는다—그냥 걸어 나간다. 바로 그게 환자들이 하고 있던 일이다.
실제 문제: 맥락 혼동
환자가 “열”이라고 언급했을 때, AI는 지식 베이스를 조회하여 수백 개의 문서—프로토콜, 약물 상호작용, 응급 기준, 보험 규정—를 가져왔습니다. AI는 이 모든 것이 도움이 될 것이라고 가정하고 공유하려 했습니다.
환자는 의료 교육을 원한 것이 아니라 화요일 오후 3시 슬롯을 원했습니다.
AI는 약속을 예약하는 데 필요한 정보와 단순히 접근할 수 있는 정보를 구분하지 못했습니다.
My First Failed Fix
제가 제한을 시도했습니다:
“명시적으로 요청받은 경우에만 의료 정보를 제공하십시오.”
그렇게 해도 효과가 없었습니다. 환자가 기침을 언급하고 의사를 만나고 싶다고 요청했습니다. AI는 “요청받지 않으면 기침 프로토콜을 설명하지 않겠습니다”라고 답한 뒤 즉시 다시 설명을 제안했습니다. 마치 뭔가에 대해 말하지 않겠다고 선언하면서 하면서 말하고 있는 어색한 사람처럼 변했습니다.
환자들은 여전히 전화를 끊었습니다.
실제 솔루션: 역할‑기반 지식 필터링
전체 프롬프트를 하나의 간단한 아이디어로 재구성했습니다:
당신은 의사가 아니라 접수 담당자입니다.
지식을 제한하는 대신 정체성을 정의했습니다.
- AI는 친절한 접수 담당자 Sarah가 되었습니다.
- 그녀의 유일한 업무: 예약 잡기 — 따뜻하고, 효율적이며, 인간적인 방식.
- 의료 지식에 접근할 수는 있지만, 예약을 위해 절대 필요할 때만 사용하도록 지시받았습니다.
- 그녀는 의료 상담자, 진단 도구, 보험 전문가, 백과사전이 아닙니다.
실제로 지식이 허용된 사용 방식
| 허용된 사용 | 예시 |
|---|---|
| 의사 전문 분야 매칭 | “소아과 의사가 필요합니다.” |
| 긴급도 평가 | “증상이 오늘 바로 보아야 할 정도로 보입니다.” |
| 기본적인 절차 안내 (예: 금식 요구) | “혈액 검사를 위해 8시간 금식해 주세요.” |
절대 사용하지 않음:
- 질환 설명
- 치료 논의
- 증상 해석
- 보험 상세 내용 파고들기
환자가 의료 질문을 하면, AI는 정중하게 다음과 같이 전환했습니다:
“그 질문은 진료 중에 의사와 상의하시면 좋을 것 같습니다. 저는 예약을 도와드리는 역할이에요. 이 시간이 괜찮으신가요?”
대화 흐름은 간단해졌습니다:
- 따뜻하게 인사하기.
- 필요 사항 물어보기.
- 가능한 슬롯 찾기.
- 확인하기.
- 완료.
목표: 2분 이내에 예약을 완료시키는 것.
변환
같은 발열 시나리오, 두 번째 시도:
AI가 우려를 인지하고, 약속 시간을 제시하고, 세부 사항을 확인한 뒤 30초 미만에 전화를 종료했습니다. 강의도, 프로토콜 설명도 없었습니다.
흉통 전화:
AI가 긴급성을 인식하고, 즉시 가능한 슬롯이나 간호사 전화를 제안하며 적절히 예약했습니다. 지식은 오직 긴급성을 분류하는 데만 사용되었으며, 심장 치료를 설명하는 데는 사용되지 않았습니다.
그 구분이 모든 것을 바꾸었습니다.
가장 어려운 부분: 그것에게 입 다물게 가르치기
- 그것에게 안 과도하게 설명하도록 말해도 효과가 없었다.
- 간결하게 해 달라고 요청해도 효과가 없었다.
- 그것을 receptionist(접수 담당자)로 정의하니 효과가 나타났다.
- 명시적으로 의학 개념을 설명하는 것이 실패와 동일함이라고 말하니 결국 작동했다.
문제 해결의 열쇠는 지식 경계가 아니라 role boundaries(역할 경계)로 문제를 정의하는 것이었다.
나에게 가장 큰 교훈을 준 엣지 케이스들
| 상황 | 성공 전략 |
|---|---|
| Worried patient needs reassurance | Acknowledge → redirect → schedule |
| Insurance question | Acknowledge → give brief logistics → hand off |
| Patient wants to discuss medical research | Acknowledge curiosity → “Great question for the doctor” → schedule |
모든 경우에 패턴은 acknowledge, redirect, schedule이었습니다.
금요일 밤을 구한 결과
| 지표 | 역할 기반 필터링 전 | 역할 기반 필터링 후 |
|---|---|---|
| 평균 통화 시간 | 2분 이상 (종종 1분 이상의 강의) | 30초 미만 |
| 포기율 | 높음 (두 자릿수 %) | 한 자릿수 % |
| 예약 성공률 | 낮음 | 크게 증가 |
| 환자 피드백 | “AI가 말을 너무 많이 했어요” | “마치 실제 접수 직원과 대화하는 느낌” |
고객은 왜 처음부터 이렇게 하지 않았는지 물었습니다. 나는 그들에게 진실을 말했습니다: 지식은 지혜와 다르다.
실제로 배운 것
정보에 접근할 수 있다는 것이 언제 그것을 사용해야 하는지를 아는 것과 동일하지 않다.
AI에 대한 명확한 역할을 정의하고, 지식 사용을 그 역할에 제한하면 시끄러운 박식가가 도움이 되고 효율적인 리셉션 담당자로 변한다.
지금 내가 따르는 프롬프트 원칙
최고의 프롬프트는 AI가 얼마나 많이 알고 있는지를 보여주는 것이 아니다.
그것은 AI가 누구에게도 과시하려 하지 않고도 자연스럽게 도움이 되는 느낌을 주는 프롬프트다—마치 훌륭한 리셉션 직원처럼 따뜻하고 효율적이며 언제 말을 해야 하고 언제 그냥 일정을 잡아야 할지 정확히 아는 것이다.
핵심 요점
- 폭보다 집중 – 적은 맥락이 종종 더 좋은 결과를 낳는다. 실제 사용자는 이상적인 테스트 대화가 숨기는 결함을 항상 드러낸다.
- AI의 역할을 한 문장으로 정의 – 이 정의를 법처럼 다뤄라. 어떤 지식이 필수이고 어떤 것이 잡음인지 냉정하게 판단하라.
- 범위 외 질문에 대비 – 사용자가 역할 밖의 질문을 할 때 AI가 어떻게 리다이렉트할지 미리 정해두라.
- 성과로 성공을 측정 – AI가 얼마나 똑똑하게 들리는가가 아니라 결과로 평가한다.
여러분 차례
- AI가 스스로에게 해가 될 정도로 너무 많은 정보를 알게 만든 적이 있나요?
- 프롬프트에서 지식베이스 범위를 어떻게 관리하나요?
- 방대한 정보를 제공했을 때 AI 응답을 어떻게 집중시킬 전략을 쓰나요?
작성자 Farhan Habib Faraz
PowerInAI 수석 프롬프트 엔지니어 & 팀 리드
일을 할 때는 조용히 하고 바로 실행하는 AI를 만든다.
Tags: knowledgebase, promptengineering, voiceai, rag, aidesign, llm