diff --git a/journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md b/journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md index 04718da..c352afc 100644 --- a/journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md +++ b/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 응답 계약 재구성 -- direct answer는 유형별 템플릿과 채택된 근거 상태를 바탕으로 생성합니다. +### Phase 4. LLM 기반 답변 생성으로 전환 +- 현재 `_build_direct_answer()` 규칙 문자열 조합을 LLM 호출로 대체합니다. +- 플로우: + 1. 근거 채택 판정을 통과한 청크를 컨텍스트로 조합 + 2. 질문 유형별 시스템 프롬프트 + 컨텍스트 + 사용자 질문을 LLM에 전달 + 3. LLM이 `직접 답 + 근거 문서명 + 요약` 형식으로 답변 생성 +- 근거가 없거나 부족할 때는 LLM에게 `문서 없음 / 문서 미확인 / 단정 불가` 중 하나로만 답하도록 프롬프트로 강제합니다. - 질문별 하드코딩 문장을 추가하지 않습니다. -- failure answer는 `문서 없음 / 문서 미확인 / 단정 불가` 중 하나로 분명히 떨어져야 합니다. ### Phase 5. 테스트 고정 및 검증 - **자동화 테스트** (코드): diff --git a/journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md b/journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md index 9880b6a..b17749a 100644 --- a/journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md +++ b/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가지를 고정해야 합니다. - 1. 질문 유형별 판정 계약 - 2. 검색 결과의 질문 적합도 판정 계약 - 3. 근거 부족 시 명시적 실패 계약 +- 그 전제가 닫힌 뒤 구현 단계에서 아래 4가지를 고정해야 합니다. + 1. 검색된 청크를 컨텍스트로 LLM에 전달해 답변을 생성하는 구조 도입 + 2. 질문 유형별 판정 계약 + 3. 검색 결과의 질문 적합도 판정 계약 + 4. 근거 부족 시 명시적 실패 계약 ## 다음 plan이 반드시 고정해야 할 항목 1. 현재 Company X RAG의 실제 임베딩 경로와 컬렉션 차원(`384d`/`768d`)을 먼저 재검증할 것