AI가 병원 정보를 지어내지 않게 하려면: Voice AI의 Grounding과 RAG 설계
환자가 병원에 전화해 묻습니다.
“주차는 어디에 하면 되나요?”
AI가 자연스러운 목소리로 곧바로 답한다고 해도, 그 내용이 실제 병원 정보와 다르면 좋은 서비스라고 할 수 없습니다. 특히 진료 시간, 검사 전 준비 사항, 비용, 주차, 예약 가능 시간처럼 환자의 행동에 직접 영향을 주는 정보는 그럴듯함보다 근거가 있는가가 훨씬 중요합니다.
병원 Voice AI에서 가장 위험한 답변은 어색한 답변이 아닙니다. 틀렸지만 너무 자연스러워서 환자가 믿게 되는 답변입니다.
이 글에서는 와이즈에이아이 인바운드 에이전트가 병원 정보를 다루는 방식을 바탕으로 다음 질문에 답해보려 합니다.
- AI가 답변에 사용할 수 있는 정보의 범위는 어디까지인가?
- 작은 FAQ와 대규모 문서 검색은 어떻게 달라야 하는가?
- Qdrant 같은 Vector Database는 언제 필요한가?
- 예약 가능 시간처럼 계속 바뀌는 정보도 RAG로 답해도 되는가?
- 답을 찾지 못했을 때 AI는 무엇을 해야 하는가?
1. LLM은 병원 데이터베이스가 아니다
대규모 언어 모델은 문장을 이해하고 자연스럽게 만드는 데 뛰어납니다. 하지만 특정 병원의 최신 운영 정보를 원래부터 알고 있는 것은 아닙니다.
예를 들어 “토요일에도 진료하나요?”라는 질문을 받았을 때 모델은 일반적인 병원의 운영 관행을 바탕으로 그럴듯한 답을 만들 수 있습니다. 그러나 해당 병원이 토요일에 휴진한다면 그 답은 잘못된 정보입니다.
따라서 병원 Voice AI에서는 LLM의 역할을 분명히 제한해야 합니다.
LLM은 병원 정보를 만들어내는 주체가 아니라, 확인된 병원 정보를 대화에 맞게 전달하는 인터페이스다.
이 원칙이 Grounding 설계의 출발점입니다.
2. Grounding과 RAG는 같은 말이 아니다
두 용어는 함께 언급되는 경우가 많지만 범위가 다릅니다.
Grounding은 AI의 답변을 확인 가능한 정보에 묶어 두는 전체 설계입니다. 시스템 프롬프트, 병원별 FAQ, 실시간 API, 검색 결과, 답변 거절 정책, 사람 상담원 연결까지 모두 포함합니다.
**RAG(Retrieval-Augmented Generation)**는 그중 필요한 문서를 검색해 LLM에게 제공하는 하나의 방법입니다.
즉, RAG를 도입했다고 해서 자동으로 Grounding이 완성되는 것은 아닙니다. 검색 결과가 부정확하거나, 오래된 문서가 검색되거나, 검색 결과에 없는 내용을 모델이 덧붙이면 여전히 환각은 발생할 수 있습니다.
3. 병원 정보는 성격에 따라 경로를 나눠야 한다
모든 정보를 하나의 검색 시스템에 넣는 방식은 단순해 보이지만 안전하지 않습니다. 정보의 성격에 따라 적절한 출처와 처리 방식이 다르기 때문입니다.
| 정보 종류 | 예시 | 적절한 정보 경로 |
|---|---|---|
| 고정된 기본 정보 | 병원 주소, 대표 전화번호 | 통화 Context |
| 자주 묻는 운영 정보 | 주차, 진료 시간, 준비물 | 병원별 검수 FAQ |
| 규모가 큰 문서형 정보 | 여러 진료과 안내, 검사별 상세 절차 | Vector Search 기반 RAG |
| 계속 바뀌는 거래 정보 | 예약 가능 시간, 예약 상태 | 실시간 업무 API |
| AI가 판단하면 안 되는 내용 | 진단, 처방, 응급 판단 | 안전 정책과 사람 상담원 |
핵심은 검색 기술을 많이 사용하는 것이 아닙니다. 질문을 가장 신뢰할 수 있는 정보원으로 보내는 것입니다.
4. 현재 서비스는 작은 FAQ를 통화 시작 전에 가져온다
와이즈에이아이 인바운드 에이전트의 기본 경로에서는 환자가 질문할 때마다 Vector Database를 검색하지 않습니다.
통화 세션을 만들 때 해당 병원에서 활성화한 FAQ를 먼저 가져오고, 질문과 답변을 에이전트의 지침에 포함합니다. 통화 중에는 LLM이 환자의 표현과 의미가 가장 가까운 FAQ를 찾아 그 답변의 사실을 그대로 전달합니다.
이 방식은 FAQ의 수가 아직 작고 엄격하게 관리되는 경우 몇 가지 장점이 있습니다.
- 통화 도중 별도의 검색 네트워크 요청이 필요하지 않습니다.
- 검색 도구를 호출할지 판단하는 LLM 단계가 줄어듭니다.
- 어떤 병원 정보가 모델에 제공되었는지 추적하기 쉽습니다.
- 짧은 음성 대화에서 응답 지연을 줄이기 유리합니다.
RAG가 최신 기술이라는 이유만으로 언제나 최선인 것은 아닙니다. 작은 지식 집합은 미리 제공하는 방식이 더 빠르고 단순할 수 있습니다.
다만 FAQ가 계속 늘어나 프롬프트가 길어지거나, 비슷한 항목이 많아져 선택 정확도가 떨어지기 시작하면 런타임 검색으로 전환할 시점입니다. 그 기준은 문서 개수 하나로 정하기보다 토큰 사용량, 응답 지연, 검색 정확도를 함께 측정해 판단해야 합니다.
5. FAQ를 제공하는 것만으로는 안전하지 않다
모델에게 병원 FAQ를 보여주는 것과 모델이 FAQ 안에서만 답하게 만드는 것은 다른 문제입니다.
현재 에이전트 지침에는 다음과 같은 경계가 포함됩니다.
- 질문의 문구가 아니라 의미를 기준으로 FAQ를 찾습니다.
- 일치하는 FAQ가 있다면 그 답변에 있는 사실만 사용합니다.
- 날짜, 시간, 금액, 수량 같은 정보는 임의로 바꾸지 않습니다.
- 관련 FAQ가 없다면 정보를 추측하거나 일반 상식으로 보완하지 않습니다.
- 확인 가능한 정보가 없다는 점을 알리고, 필요하면 사람 상담원 연결을 안내합니다.
- 의료 조언이나 진단은 제공하지 않습니다.
예를 들어 FAQ에 “평일 오전 9시부터 오후 6시까지”라고 적혀 있다면 AI가 “대부분 6시 반까지 접수할 수 있습니다”라고 친절하게 덧붙여서는 안 됩니다. 자연스러운 보충 설명처럼 들려도 병원이 확인하지 않은 새로운 사실이기 때문입니다.
Grounding의 품질은 얼마나 많은 정보를 답하느냐보다 근거 밖으로 나가지 않는가에서 드러납니다.
6. FAQ 조회 실패가 통화 실패가 되면 안 된다
외부 FAQ API가 잠시 응답하지 않거나 해당 병원에 등록된 FAQ가 없을 수도 있습니다. 이때 통화 전체를 종료하면 환자는 주소 확인이나 예약처럼 여전히 처리할 수 있는 업무까지 이용하지 못합니다.
현재 구조는 FAQ를 가져오지 못해도 제한된 상태로 통화를 계속할 수 있도록 설계되어 있습니다.
이것은 단순한 장애 대응이 아닙니다. AI가 지금 어떤 정보를 가지고 있는지를 인식하고, 그 범위 안에서만 행동하도록 만드는 안전 설계입니다.
7. 검색 도구가 없어도 정보 안내 성공을 측정해야 한다
질문마다 검색 도구를 호출한다면 도구 실행 기록으로 정보 안내 성공 여부를 알 수 있습니다. 하지만 FAQ를 미리 제공하는 구조에서는 별도의 검색 호출이 발생하지 않습니다.
그래도 운영 관점에서는 “이번 통화에서 병원 정보를 제대로 안내했는가?”를 측정해야 합니다.
이를 위해 통화 후 에이전트가 실제로 말한 문장과 병원의 FAQ 답변을 정규화해 비교할 수 있습니다. 충분히 가까운 답변이 확인되면 정보 안내 성공 이벤트로 기록합니다.
이 비교는 추가 LLM 호출이나 네트워크 검색 없이 수행할 수 있습니다. 따라서 환자가 답변을 기다리는 시간에는 영향을 주지 않으면서, 사후 분석에 필요한 관측 가능성을 확보합니다.
중요한 점은 “답할 수 없습니다”라는 안전한 거절을 FAQ 안내 성공으로 잘못 세지 않는 것입니다. 성공률과 안전한 거절률은 별도의 지표로 보아야 합니다.
8. 지식이 커지면 Qdrant Vector Search가 필요해진다
병원별 지식이 몇 개의 FAQ를 넘어 진료과 안내, 검사 준비 절차, 증명서 발급 방법, 층별 시설 안내처럼 커지면 모든 내용을 프롬프트에 넣기 어렵습니다.
이 단계에서는 문서를 작은 단위로 나누어 임베딩하고, Qdrant 같은 Vector Database에 저장한 뒤 질문과 가까운 일부 문서만 가져오는 RAG 구조가 유리합니다.
Qdrant에서는 하나의 포인트가 벡터와 선택적인 payload로 구성됩니다. payload에는 병원 ID, 지점, 주제, 문서 버전, 활성 여부 같은 메타데이터를 넣을 수 있습니다. 이 메타데이터는 단순한 부가 정보가 아니라 다른 병원의 문서가 검색되는 것을 막는 핵심 안전장치입니다.
9. Vector Search에서는 유사도만 보면 안 된다
의미가 비슷하다는 이유만으로 사용할 수 있는 문서라고 판단하면 안 됩니다.
예를 들어 같은 검사를 설명하는 문서라도 지점마다 운영 시간이 다를 수 있고, 예전 문서가 더 높은 유사도 점수를 받을 수도 있습니다. 따라서 검색은 최소한 다음 조건을 함께 확인해야 합니다.
| 조건 | 확인할 질문 |
|---|---|
| Tenant | 현재 통화 중인 병원의 문서인가? |
| Site | 올바른 지점의 문서인가? |
| Status | 현재 활성화된 정보인가? |
| Version | 최신 검수본인가? |
| Topic | 환자의 질문 범주와 맞는가? |
| Score | 사용할 만큼 관련성이 높은가? |
Qdrant의 score threshold는 관련성이 낮은 결과를 제외하는 데 사용할 수 있습니다. 다만 적절한 임계값은 임베딩 모델, 거리 기준, 문서 구성에 따라 달라지므로 실제 병원 질문 데이터로 평가해야 합니다.
검색 결과가 기준보다 낮으면 “가장 가까운 문서라도 일단 사용”하는 것이 아니라 검색 실패로 인정하는 것이 더 안전합니다.
10. 의미 검색과 정확한 단어 검색을 함께 사용한다
음성 대화에서는 환자가 병원 문서와 다른 표현을 사용합니다.
- “위내시경 전에 밥 언제부터 못 먹어요?”
- “검사 전 금식 시간이 궁금해요.”
이런 표현 차이는 의미 기반 Dense Vector Search가 잘 처리합니다.
반면 약 이름, 검사 코드, 진료과 이름, 숫자처럼 정확한 단어가 중요한 질문은 키워드 기반 Sparse Search가 유리할 수 있습니다. 두 방식을 결합한 Hybrid Search는 각각의 약점을 보완합니다.
후보를 넓게 찾은 뒤 더 정교한 모델로 순서를 다시 매기는 reranking도 사용할 수 있습니다. 다만 Voice AI에서는 정확도 향상만큼 응답 지연도 중요하므로, 검색 단계가 늘어날 때마다 실제 통화 기준으로 효과를 검증해야 합니다.
11. RAG를 붙여도 환각은 사라지지 않는다
RAG는 모델에게 근거를 제공하지만, 모델이 그 근거를 잘못 해석하거나 없는 내용을 덧붙이는 문제까지 자동으로 막아주지는 않습니다.
따라서 생성 단계에도 별도의 규칙이 필요합니다.
- 검색된 문서에 있는 사실만 답합니다.
- 서로 충돌하는 문서가 나오면 임의로 하나를 선택하지 않습니다.
- 답변에 필요한 핵심 정보가 빠져 있으면 완성된 것처럼 말하지 않습니다.
- 숫자와 시간은 원문을 보존합니다.
- 근거가 부족하면 모른다고 말합니다.
- 병원 직원이 확인해야 하는 내용은 상담원 연결을 제안합니다.
이때 “모른다”는 답은 시스템 실패가 아닙니다. 잘못된 정보를 자신 있게 전달하지 않은 안전한 성공일 수 있습니다.
12. 예약 가능 시간은 RAG로 답하지 않는다
예약 슬롯은 문서 지식이 아니라 현재 상태입니다. 몇 초 전에는 비어 있던 시간이 다른 환자의 예약으로 채워질 수 있습니다.
따라서 예약 가능 시간을 FAQ나 Vector Database에 넣고 답하는 것은 적절하지 않습니다. Voice AI가 예약 API를 호출해 현재 가능한 시간을 조회하고, 환자가 선택하면 다시 API를 통해 예약을 확정해야 합니다.
정리하면 문서형 정보는 FAQ나 RAG로, 거래형 정보는 업무 API로 처리해야 합니다. 두 경로를 섞지 않는 것이 데이터 신선도와 책임 범위를 명확하게 만듭니다.
13. 의료 질문은 검색 정확도보다 역할 경계가 먼저다
“이 증상이면 어떤 병인가요?”라는 질문과 “건강검진 전날 몇 시부터 금식하나요?”라는 질문은 모두 의료와 관련되어 보이지만 Voice AI가 맡아야 할 역할은 다릅니다.
검수된 병원 안내문에 있는 검사 준비 사항은 정확히 전달할 수 있습니다. 그러나 증상을 바탕으로 진단하거나 처방을 제안해서는 안 됩니다.
응급 가능성이 있는 표현은 일반 FAQ 검색보다 안전 정책이 먼저 작동해야 합니다. 환자에게 필요한 긴급 안내를 제공하고, 설정된 절차에 따라 사람 상담원이나 적절한 채널로 연결해야 합니다.
Grounding은 AI가 무엇을 아는지만 정하는 것이 아니라 무엇을 판단하지 않을지도 정하는 설계입니다.
14. 좋은 RAG는 정답률만 평가하지 않는다
병원 Voice AI의 지식 시스템을 평가할 때는 질문에 답했는지만 보면 안 됩니다.
| 지표 | 의미 |
|---|---|
| Retrieval Recall | 필요한 근거 문서를 후보에 포함했는가? |
| Grounded Answer Rate | 답변의 사실이 제공된 근거 안에 있는가? |
| Safe Abstention Rate | 근거가 없을 때 추측하지 않았는가? |
| Cross-tenant Error | 다른 병원 정보가 섞이지 않았는가? |
| Freshness Error | 오래된 정보로 답하지 않았는가? |
| API Routing Accuracy | 실시간 정보를 문서 검색으로 처리하지 않았는가? |
| Response Latency | 환자가 기다릴 수 있는 시간 안에 답했는가? |
| Handoff Appropriateness | 사람이 필요한 상황을 적절히 넘겼는가? |
특히 “답변률 100%”는 좋은 목표가 아닐 수 있습니다. 근거가 없는 질문까지 모두 답했다면 환각이 늘었을 가능성이 있기 때문입니다.
평가 데이터에는 정상 질문뿐 아니라 다음과 같은 경계 사례도 포함해야 합니다.
- 다른 병원이나 지점의 정보를 묻는 질문
- FAQ에 없는 비용을 집요하게 묻는 질문
- 오래된 운영 시간을 전제로 한 질문
- 비슷한 이름의 검사나 약을 혼동하기 쉬운 질문
- 하나의 문장에 예약과 의료 조언 요청이 섞인 질문
- STT가 숫자나 고유명사를 잘못 인식한 질문
15. 안전한 답변은 검색보다 먼저 설계된다
병원 Voice AI의 RAG 설계는 “어떤 Vector Database를 사용할 것인가?”에서 시작하지 않습니다.
먼저 정보의 성격과 책임 범위를 구분해야 합니다.
- 작은 검수 FAQ는 통화 시작 전에 제공해 빠르게 답합니다.
- 커진 문서 지식은 Qdrant에서 병원별로 안전하게 검색합니다.
- 예약처럼 변하는 정보는 실시간 API로 확인합니다.
- 의료 판단과 불확실한 질문은 AI가 채우지 않습니다.
- 답을 찾지 못하면 정직하게 알리고 사람에게 연결합니다.
- 통화 후에는 어떤 근거로 무엇을 답했는지 측정합니다.
좋은 Voice AI는 모든 질문에 답하는 AI가 아닙니다.
확인된 정보는 빠르고 정확하게 전달하고, 확인되지 않은 정보는 지어내지 않는 AI다.
이 원칙이 지켜질 때 자연스러운 음성 경험과 병원 서비스에 필요한 신뢰를 함께 만들 수 있습니다.