주어진 맥락이나 지식베이스를 바탕으로 자연어 질문에 정확한 답을 찾아내는 AI 기능. RAG 시스템의 가장 핵심적인 응용 패턴이다.
질의응답은 사람이 던진 자연어 질문을 AI가 이해하고 그에 맞는 답을 돌려주는 기능이다. 검색창에 키워드를 넣으면 그 단어가 들어간 문서 목록이 쭉 나오는 것과는 다르다. "작년에 우리 회사 환불 정책이 어떻게 바뀌었지?"라고 물으면, AI는 이 문장이 무엇을 궁금해하는지 파악하고 관련 내용이 담긴 문서를 찾아 실제 답 한 줄을 만들어 준다. 문서 목록이 아니라 "이거예요"라는 답을 준다는 점이 핵심이다.
답을 만드는 방식은 크게 두 갈래로 나뉜다. 하나는 원문에서 답에 해당하는 부분을 그대로 오려 오는 방식이고, 다른 하나는 여러 문서에서 얻은 정보를 AI가 자기 말로 다시 풀어 쓰는 방식이다. 앞의 것은 원문에 형광펜을 긋는 것과 같아서 출처를 그대로 확인할 수 있고 틀릴 여지가 적다. 뒤의 것은 흩어진 정보를 자연스러운 문장으로 종합해 주지만, 없는 내용을 그럴듯하게 지어낼 위험이 함께 따라온다.
요즘 질의응답을 구현하는 가장 흔한 방법은 RAG다. 사용자의 질문을 숫자 벡터로 바꾼 뒤 벡터 데이터베이스에서 의미가 비슷한 문서 조각을 찾아오고, 그 조각들을 질문과 함께 LLM에 넣어 답을 쓰게 하는 흐름이다. 사내 규정 챗봇을 만든다면 회사 문서만 벡터로 저장해 두고 그 안에서만 답을 찾게 한다. 반대로 인터넷 전체를 뒤져 아무 질문에나 답하게 하려면 훨씬 넓은 범위에서 검색해야 하는데, 앞의 것을 닫힌 도메인, 뒤의 것을 열린 도메인 질의응답이라고 부른다.
답의 품질은 두 단계 모두에 달려 있다. 아무리 똑똑한 LLM이라도 엉뚱한 문서를 가져오면 좋은 답이 나올 수 없고, 정확한 문서를 찾아 줘도 LLM이 잘못 읽으면 소용없다. 그래서 실무에서는 "검색이 제대로 됐는가"와 "읽고 답한 게 맞는가"를 따로 뜯어보며 다듬는다.
가장 까다로운 건 여러 문서를 이어 붙여야 답이 나오는 질문이다. "이 제품을 만든 팀장이 그 전에 다니던 회사는?"처럼 한 번의 검색으로 끝나지 않고, 팀장을 찾고 다시 그 사람의 이력을 찾는 여러 단계를 거쳐야 하는 경우를 멀티홉 질의응답이라 한다. 중간에 한 고리만 어긋나도 최종 답이 무너지기 쉽다.
또 하나는 성능을 어떻게 재느냐다. 흔히 정답과 얼마나 겹치는지로 점수를 매기지만, AI가 표현만 다르게 맞는 답을 해도 글자가 안 겹치면 틀린 것으로 깎이기도 한다. 무엇보다 생성 방식은 검색 결과에 답이 없을 때조차 그럴듯한 문장을 지어내는 환각이 문제라서, 답에 근거 문서를 함께 붙여 사용자가 직접 확인할 수 있게 만드는 것이 안전한 설계다.