26. 검색·도구와 결합하기 (RAG·도구 사용)

모델 혼자서는 못 하는 것들

21장에서 모델의 능력 한계를 봤습니다 — 최신 정보, 실시간 데이터, 정밀 계산, 비공개 자료. 이런 작업은 프롬프트를 아무리 다듬어도 모델 내부 지식만으로는 해결되지 않습니다. 답은 모델을 외부와 연결하는 것입니다. 크게 두 가지입니다.

• 검색 결합(RAG): 외부 자료에서 관련 정보를 찾아와 컨텍스트에 넣어주기
• 도구 사용(function calling): 모델이 계산기·검색·DB·API 같은 도구를 호출하게 하기

이 장은 둘을 프롬프트·컨텍스트 관점에서 봅니다. 시스템 구축의 세부보다, "이것이 프롬프트 설계에 어떤 의미인가"에 집중합니다.

RAG — 검색 증강 생성

RAG(Retrieval-Augmented Generation)는 16장에서 살짝 봤습니다. 핵심은 단순합니다: 질문이 들어오면, 대량의 문서에서 관련된 부분만 검색해 컨텍스트에 넣고, 그것을 근거로 답하게 하는 것입니다.

flowchart LR
    q["질문"] --> search["관련 문서 검색"]
    search --> ctx["검색된 조각을<br/>컨텍스트에 삽입"]
    ctx --> gen["근거 기반 생성"]
    gen --> a["답변 (+ 출처)"]

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef ctx fill:#ede9fe,stroke:#8b5cf6,color:#4c1d95
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class q,search,gen step
    class ctx ctx
    class a good

RAG는 3부의 직접 적용이다

RAG를 따로 외울 필요가 없는 이유: 이미 배운 컨텍스트 원칙의 자동화이기 때문입니다.

📌 핵심: RAG의 품질은 "검색이 정말 관련된 것을 가져오는가"에 달려 있습니다. 엉뚱한 자료를 가져오면, 그것이 컨텍스트에 들어가 모델을 엉뚱한 답으로 이끕니다(3장 컨텍스트 의존의 나쁜 면). 좋은 검색 = 좋은 컨텍스트 = 좋은 답입니다.

RAG의 프롬프트 측면

검색이 자료를 가져온 뒤, 그 자료를 어떻게 쓰게 할지는 프롬프트의 몫입니다. 16장의 4원칙이 그대로 적용됩니다.

✅ (검색된 조각이 <자료>에 삽입된다고 가정)
"아래 검색된 자료에만 근거해 답하세요.
- 자료에 근거가 없으면 '관련 정보를 찾지 못했습니다'라고 하세요.
- 각 주장에 출처 자료 번호를 표시하세요.
<자료>{검색 결과}</자료>
질문: {사용자 질문}"

⚠️ 흔한 실수·미신: "RAG를 붙였으니 환각이 사라진다"는 과신입니다. RAG는 환각을 줄이지만 없애지 못합니다. 검색이 관련 없는 자료를 가져오거나, 모델이 자료를 무시하고 내부 지식으로 답하면(16장 충돌) 여전히 틀립니다. "자료 우선"과 "없으면 모른다"를 명시하고, 출처 대조로 검증하세요(18·20장).

비개발자의 "검색 결합"

RAG는 시스템이지만, 그 정신은 누구나 씁니다. 챗 도구의 웹 검색 기능이나, 관련 자료를 직접 찾아 붙여넣는 것도 같은 원리입니다 — 모델 밖 정보를 가져와 근거로 주는 것.

💡 팁: 최신 사실이 필요한 질문에는, 모델의 기억에 의존하지 말고 검색 기능을 켜거나 관련 자료를 직접 제공하세요. 그리고 "이 자료에 근거해", "출처를 밝혀" 같은 16장 지시를 함께 주면, 붙여넣기만 할 때보다 훨씬 믿을 만한 답이 나옵니다.

도구 사용 (function calling)

한 발 더 나아가, 모델이 스스로 도구를 호출하게 할 수 있습니다. 계산이 필요하면 계산기를, 최신 정보가 필요하면 검색을, 데이터가 필요하면 DB를 호출하는 식입니다. 모델은 "언제 어떤 도구를 어떤 입력으로 부를지" 결정하고, 도구의 결과를 받아 답에 반영합니다.

이는 21장의 능력 한계를 정면으로 푸는 방법입니다 — 못하는 일은 잘하는 도구에 맡기는 것이죠.

🔧 개발자 노트: function calling(또는 tool use)은 API에서 모델에게 사용 가능한 도구의 명세(이름·설명·입력 스키마)를 주면, 모델이 필요할 때 "이 도구를 이 입력으로 호출하겠다"는 구조화된 출력을 냅니다. 시스템이 실제로 도구를 실행하고 결과를 모델에게 돌려주면, 모델이 그걸로 답을 잇습니다. 프롬프트 설계의 핵심은 ① 도구 설명을 명확히 쓰는 것(모델이 언제 쓸지 판단하는 근거가 됨 — 5장 명확성이 도구 설명에도 적용), ② 도구가 여럿이면 각 용도 경계를 분명히, ③ 도구 결과를 컨텍스트에 넣을 때 3부 원칙(필요한 것만, 깨끗하게) 적용입니다. 도구 명세가 모호하면 모델이 엉뚱한 도구를 부르거나 안 불러야 할 때 부릅니다.

도구 사용의 프롬프트 관점

도구를 쓸 때도 결국 프롬프트가 관여합니다. 모델이 도구를 언제 써야 하는지 안내하고, 결과를 어떻게 해석·종합할지 지시해야 합니다.

✅ (도구가 연결된 환경에서)
"계산이 필요하면 추측하지 말고 계산 도구를 사용해.
최신 정보가 필요하면 검색 도구를 사용해.
도구 결과를 종합해 답하고, 어떤 도구를 썼는지 밝혀줘."

큰 그림 — 모델은 "추론 엔진", 도구는 "감각·손발"

정리하면, 외부 결합의 철학은 이렇습니다. 모델이 모든 것을 알아야 한다고 기대하지 마세요. 대신 모델을 판단·종합하는 엔진으로 두고, 사실·계산·실시간 정보는 도구가 공급하게 하세요. 이 분업이 신뢰성을 크게 높입니다.

🧪 직접 검증법: 최신 정보나 계산이 필요한 질문을, (a) 모델 단독과 (b) 검색/계산 결합으로 각각 물어 정확도를 비교해보세요. 사실성·시의성 작업에서 결합 쪽이 분명히 나을 겁니다. 차이가 클수록, 그 작업은 모델 단독에 맡기면 안 되는 작업입니다.

이 장에서 배운 것

• 모델 내부 지식만으로 안 되는 작업(최신성·실시간·정밀계산·비공개 자료)은 외부 결합으로 푼다: RAG(자료 가져오기)와 도구 사용(도구 호출하기).
• RAG는 3부 컨텍스트 원칙의 자동화다. 검색이 관련 자료를 가져와야 좋은 답이 나오며, RAG도 환각을 줄일 뿐 없애지 못한다.
• 검색 결합의 정신은 비개발자도 쓴다 — 검색 기능 켜기, 자료 직접 붙여넣기 + 16장 지시.
• 도구 사용은 모델이 스스로 도구를 호출하는 것으로, 도구 설명의 명확성과 결과의 컨텍스트 관리가 프롬프트 핵심이다.
• 큰 그림: 모델은 추론 엔진, 도구는 사실·계산·실시간을 공급하는 감각·손발. 이 분업이 신뢰성을 높인다.

✍️ 확인 문제

1. "RAG를 붙이면 환각이 완전히 사라진다"는 주장의 어디가 틀렸는지, 검색 품질과 16장 충돌 처리를 들어 설명해보세요.

1. RAG의 네 요소가 각각 3부의 어떤 장 원칙과 대응하는지 연결해보세요.

1. (실습) "우리 회사 최신 환불 정책으로 고객 질문에 답하는" 작업을, (비개발자라면) 검색/붙여넣기 결합으로, (개발자라면) RAG 흐름으로 설계해보세요. 16장 지시를 어떻게 넣을지 포함하세요.

다음 → 27. 시스템 프롬프트 설계
이전 ← 25. 자기 비판과 자기 수정 유도 · 목차