docs: 진짜 RAG 구조(LLM 컨텍스트 기반 답변 생성) 명시

리서치 Fact 7: 현재 구조는 RAG가 아님을 명시. 검색만 있고 LLM 생성이
없는 규칙 기반 문자열 조합임을 지적. LLM 기반 전환 필요 방향 추가.
리서치 결론: 가장 근본 원인으로 RAG 구조 부재 추가. 구현 항목 4가지로 갱신.
계획 구현 원칙: RAG 전환 플로우(임베딩→검색→청크선별→LLM→답변) 명시.
계획 Phase 4: 규칙 문자열 조합 → LLM 호출로 대체하는 구체적 플로우 추가.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md

@@ -86,7 +86,11 @@ tags: [plans, companyx, rag, answer-composition, scenario, troubleshooting]
   - `내부 문서만으로는 단정 불가`
 
 ## 4. 구현 원칙
-- `SKILL.md`의 답변 순서(`direct answer -> evidence documents -> short evidence summary`)를 코드 계약으로 내립니다.
+- **RAG 구조 전환**: 현재 규칙 기반 문자열 조합은 RAG가 아닙니다. 검색된 청크를 컨텍스트로 LLM에 전달해 답변을 생성하는 구조로 전환합니다.
+  - 플로우: 질문 임베딩 → pgvector 유사도 검색 → 적합 청크 선별 → LLM 컨텍스트 전달 → 답변 생성
+  - LLM: 현재 rb8001 기준 모델 사용 (gpt-4o-mini 계열)
+  - 근거 부족 시 LLM에게 "문서 없음"을 명시적으로 지시하는 시스템 프롬프트 포함
+- `SKILL.md`의 답변 순서(`direct answer -> evidence documents -> short evidence summary`)를 LLM 프롬프트 계약으로 내립니다.
 - 질문별 direct answer 하드코딩을 더 늘리지 않습니다.
 - 질문 유형 판정과 근거 채택 판정은 별도 함수로 분리합니다.
 - `검색됨`과 `답할 수 있음`을 같은 상태로 취급하지 않습니다.
@@ -140,10 +144,14 @@ tags: [plans, companyx, rag, answer-composition, scenario, troubleshooting]
   - 답변 가능 근거인지 여부
 - `휴가` 질문에 `todaytradition` 청크가 잡히는 경우는 `무관한 결과`로 실패 처리해야 합니다.
 
-### Phase 4. direct/failure 응답 계약 재구성
+### Phase 4. LLM 기반 답변 생성으로 전환
-- direct answer는 유형별 템플릿과 채택된 근거 상태를 바탕으로 생성합니다.
+- 현재 `_build_direct_answer()` 규칙 문자열 조합을 LLM 호출로 대체합니다.
+- 플로우:
+  1. 근거 채택 판정을 통과한 청크를 컨텍스트로 조합
+  2. 질문 유형별 시스템 프롬프트 + 컨텍스트 + 사용자 질문을 LLM에 전달
+  3. LLM이 `직접 답 + 근거 문서명 + 요약` 형식으로 답변 생성
+- 근거가 없거나 부족할 때는 LLM에게 `문서 없음 / 문서 미확인 / 단정 불가` 중 하나로만 답하도록 프롬프트로 강제합니다.
 - 질문별 하드코딩 문장을 추가하지 않습니다.
-- failure answer는 `문서 없음 / 문서 미확인 / 단정 불가` 중 하나로 분명히 떨어져야 합니다.
 
 ### Phase 5. 테스트 고정 및 검증
 - **자동화 테스트** (코드):

journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md

@@ -100,8 +100,10 @@ tags: [research, companyx, rag, answer-composition, scenario, troubleshooting]
 - 위치:
   - `rb8001/app/services/companyx_grounding_service.py:130-171`
 - 의미:
-  - 현재 이 문제의 본질은 `프롬프트가 약해서`라기보다, `규칙 설계가 질문 유형을 감당하지 못하는 상태`입니다.
+  - 이것은 RAG가 아닙니다. RAG의 정의는 검색된 청크를 컨텍스트로 LLM에 전달해 답변을 생성하는 구조입니다.
-  - 다만 구현 형태는 질문별 문장/분기 하드코딩에 의존하고 있어 유지보수성이 낮습니다.
+  - 현재 구조는 검색(Retrieval)만 있고 LLM 기반 생성(Generation)이 없습니다.
+  - 따라서 현재 구현 형태는 질문별 문장/분기 하드코딩에 의존하고 있어 유지보수성이 낮고, 질문 유형을 감당하지 못합니다.
+  - **진짜 RAG로 전환**: 검색된 청크를 컨텍스트로 LLM(현재 gpt-4o-mini)에 전달해 답변을 생성하는 구조로 바꿔야 합니다.
 
 ### 8. 스킬 문서가 요구하는 계약과 현재 구현 계약은 일치하지 않는다
 - `SKILL.md`는 답변 순서를 `direct answer -> evidence documents -> short evidence summary`로 고정합니다.
@@ -238,12 +240,14 @@ tags: [research, companyx, rag, answer-composition, scenario, troubleshooting]
 ## 결론
 - 이 이슈의 직접 원인은 `Company X 검색 실패`가 아니라 `질문 적합 근거 선별 없는 답변 합성`입니다.
 - 더 근본 원인은 `질문 유형 계약 없이 일부 질문만 하드코딩 특례 처리하는 구조`입니다.
+- **가장 근본 원인**: 현재 구조는 RAG가 아닙니다. 검색된 청크를 LLM 컨텍스트로 전달해 답변을 생성하는 구조가 없고, 규칙 기반 문자열 조합으로 대체하고 있습니다. 이를 진짜 RAG 구조로 전환해야 합니다.
 - 다만 현재는 `NAS 대량 문서 운영 상태`와 `Gemini Embedding 2 전환 상태`가 겹쳐 있으므로, 다음 plan은 구현 전에 운영 전제 재검증부터 고정해야 합니다.
 - PostgreSQL 저장 경로 전제는 확정됐으므로, plan에서는 이를 기준으로 재검증/테스트 항목을 정렬해야 합니다.
-- 그 전제가 닫힌 뒤 구현 단계에서 아래 3가지를 고정해야 합니다.
+- 그 전제가 닫힌 뒤 구현 단계에서 아래 4가지를 고정해야 합니다.
-  1. 질문 유형별 판정 계약
+  1. 검색된 청크를 컨텍스트로 LLM에 전달해 답변을 생성하는 구조 도입
-  2. 검색 결과의 질문 적합도 판정 계약
+  2. 질문 유형별 판정 계약
-  3. 근거 부족 시 명시적 실패 계약
+  3. 검색 결과의 질문 적합도 판정 계약
+  4. 근거 부족 시 명시적 실패 계약
 
 ## 다음 plan이 반드시 고정해야 할 항목
 1. 현재 Company X RAG의 실제 임베딩 경로와 컬렉션 차원(`384d`/`768d`)을 먼저 재검증할 것