---
tags: [robeing, companyx, rag, research, internal-documents, grounding]
status: closed
closed_date: 2026-03-21
closed_reason: 발견한 문제(근거 연결 부재, 의도 분류 실패, 인덱스 부족)는 260315→260320→260321 계획으로 전부 해소. 200개 인덱싱 + 3중 검색 + LLM 합성 동작 확인.
---

# 260312 Company X 내부문서 RAG 근거응답 현황 리서치

## 상위 원칙
- [Writing Principles](../../../../0_VALUE/20_Governance/writing-principles.md)
- [Company X 내부 문서 RAG 응답 아이디어](../ideas/260312_companyx_내부문서_rag_응답_아이디어.md)
- [Company X 내부 문서 근거응답 사용자 시나리오](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)

## 목적
- Company X 소속 사용자가 `오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?`라고 물었을 때,
  현재 실제 로빙이 어떤 답을 하는지 확인한다.
- 현재 로빙이 Company X 내부 NAS 문서를 근거로 답할 수 있는 구조인지 확인한다.
- NAS 원본에는 실제 근거가 있는지 확인해, 문제를 `근거 부재`와 `근거 연결 부재`로 구분한다.
- 이 문서 하나로 기존 `ideas`와 `scenarios`를 `plans`로 넘길 수 있는 사실 기준을 고정한다.

## 조사 범위
- 런타임 서비스: `rb8001`, `skill-rag-file`
- 저장 상태: `team_document`, Chroma 컬렉션 검색 결과
- 원본 데이터: 내부 NAS `/mnt/nas/workspace/6.Company X`
- 대표 질문: `오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?`

## Facts

### 1. 현재 실제 로빙 답변은 내부 문서 근거답변이 아니다

- 2026-03-12 21:24 KST 기준 `rb8001` 테스트 엔드포인트에 대표 질문을 직접 넣어 확인했다.
- 호출 경로:
  - `POST /api/test/router-message`
- 입력:
  - `오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?`
- 실제 응답:

```json
{
  "user_id": "53529291-5050-4daa-89fb-008b546feb63",
  "user_message": "오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?",
  "bot_response": "CTO님, Company X가 옐로펀치와 함께 전통 프로그램을 운영한다는 근거를 찾아보겠습니다. 관련 정보를 확인해 보고 말씀드리겠습니다.",
  "intent": null,
  "skill_sequence": null,
  "status": "success"
}
```

- 이 응답은 문서명, 문단 요약, 파일 위치를 전혀 제시하지 않는다.
- 즉 현재 시나리오가 기대하는 `직접 답변 + 근거 문서` 형식과 다르다.

### 2. 현재 질문은 라우터에서 `UNKNOWN`으로 떨어지고 내부 문서 검색으로 연결되지 않는다

- 같은 시각 `rb8001` 로그에서 아래 사실을 확인했다.
  - DecisionEngine이 해당 질문에 대해 `의도 매칭 실패 - UNKNOWN`을 기록했다.
  - 이후 응답은 내부 LLM 경로로 생성됐다.
- 확인된 로그 핵심:
  - `Loaded 0 recent conversations`
  - `[DecisionEngine] 의도 매칭 실패 - UNKNOWN으로 처리`
  - 이후 Gemini 호출 발생
- 따라서 현재 로빙은 이 질문을 `Company X 내부 문서 근거 확인` 작업으로 해석하지 못한다.

### 3. 현재 `skill-rag-file` 인덱스에는 관련 Company X 문서가 없다

- `skill-rag-file` DB(`team_document`)를 직접 확인한 결과 총 문서 수는 `136`건이었다.
- 최근 적재 문서들은 `/mnt/51123data/documents/...` 또는 `/mnt/nas/documents/...` 아래의 일반 업로드 문서였고, 대표 예시는 아래와 같았다.
  - `06_릴라이 와이어프레임.pdf`
  - `01_후인터 사업계획서 ppt버전.pdf`
  - `에이징랩(주)_IR_20260309_v1.pdf`
- 같은 DB에서 아래 조건으로 조회했을 때 결과가 `0건`이었다.
  - `filename ilike '%오늘전통%'`
  - `filename ilike '%옐로%'`
  - `storage_path ilike '%오늘전통%'`
  - `storage_path ilike '%옐로%'`
- 따라서 현재 RAG 인덱스에는 적어도 `오늘전통`, `옐로펀치` 관련 Company X 문서가 들어가 있지 않다.

### 4. 현재 `skill-rag-file` 검색으로도 관련 결과를 찾지 못했다

- `skill-rag-file` 검색 API에 대표 질문을 그대로 넣어 테스트했다.
- 호출 경로:
  - `POST /api/search`
- 사용한 team 식별자는 테스트 사용자 UUID였고, 결과는 아래와 같았다.

```json
{
  "query": "오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거",
  "results": [],
  "total_results": 0
}
```

- 위 결과만으로 `모든 team_id에서 절대 검색 불가`를 단정할 수는 없다.
- 그러나 바로 위 3번 사실 때문에, 현재 인덱스 DB 전체에 관련 문서가 없다는 점은 별도로 확인됐다.

### 5. 내부 NAS 원본에는 질문과 직접 관련된 근거 문서가 실제로 존재한다

- 내부 NAS에서 `오늘전통`, `옐로펀치` 키워드로 파일명을 조사한 결과 관련 문서가 다수 존재했다.
- 대표 경로 예시:
  - `/mnt/nas/workspace/6.Company X/2. 신규운영사 및 펀드 운용사, 용역 프로그램 제안 등/2025년/05. [한국공예·디자인문화진흥원] 오늘전통 5기 초기창업기업 창업기획자(액셀러레이터) 공모/01. 제출서류/01. 사업계획서_컴퍼니엑스.pdf`
  - `/mnt/nas/workspace/6.Company X/10. MOU&인증/옐로펀치/TalkFile_MOU_옐로펀치X컴퍼니엑스- 25.01.23.pdf.pdf`

### 6. `오늘전통 5기 사업계획서`에는 옐로펀치가 협력기관으로 명시돼 있다

- 위 `사업계획서_컴퍼니엑스.pdf`를 텍스트 추출해 확인했다.
- 확인된 핵심 구절:
  - `프렉클컴퍼니, 스몰브랜더, 옐로펀치 등 브랜드 기업의 성장 지원이 가능한 외부 협력체계를 기반으로`
  - `㈜옐로펀치`
  - `공동 및 후속투자`
- 해석상 이 문서는 최소한 `오늘전통 사업계획서 안에서 옐로펀치가 Company X의 대외 협력체계/협력기관 중 하나로 제시된다`는 근거가 된다.

### 7. `옐로펀치X컴퍼니엑스 MOU`에는 공동 컨소시엄 협력과 프로그램 운영 참여가 명시돼 있다

- `TalkFile_MOU_옐로펀치X컴퍼니엑스- 25.01.23.pdf.pdf`를 텍스트 추출해 확인했다.
- 확인된 핵심 구절:
  - `주식회사옐로펀치와 주식회사컴퍼니엑스는 우수 창업기업 발굴, 투자·육성 업무 활성화를 위해 아래의 협약을 체결`
  - `교육, 멘토링, 세미나, IR 등 기업 육성 프로그램 운영 참여`
  - `예비창업자 및 초기 창업기업 대상 지원사업 공동 컨소시엄 협력`
- 이 문서는 `Company X와 옐로펀치 간 공식 협력 관계`를 뒷받침한다.

### 8. 따라서 현재 문제는 `근거 없음`이 아니라 `근거 연결 부재`다

- NAS 원본에는 관련 근거가 있다.
- 그러나 현재 로빙 런타임은 이 질문을 문서 근거 확인으로 해석하지 못한다.
- 또한 관련 원본 문서가 `skill-rag-file` 인덱스에 들어가 있지 않다.
- 즉 현재 실패 원인은 `Company X 문서가 실제로 없어서`가 아니라, `있지만 로빙 답변 경로와 연결되지 않아서`다.

### 9. 현재 로빙 임베딩 경로 기준 실제 문서 인덱싱 시간은 수초~수십초가 아니라 수초 단위다

- `skill-rag-file` 실제 `/api/upload` 경로로 Company X 문서 2개를 직접 인덱싱해 시간을 확인했다.
- 유효한 기존 team_id를 사용해 `업로드 -> 텍스트 추출 -> 청킹 -> 임베딩 -> Chroma 저장`까지 포함한 전체 시간을 측정했다.
- 측정 결과:
  - `옐로펀치X컴퍼니엑스 MOU` PDF `130,944B`: `0.608초`, `5 chunks`
  - `오늘전통 사업계획서_컴퍼니엑스` PDF `12,937,755B`: `8.371초`, `104 chunks`
- 인덱싱 후 검색 시간도 확인했다.
  - 질의 `공동 컨소시엄 협력`
  - 검색 응답 시간: `0.059초`
  - 결과: MOU 문서 청크 1건 반환

### 10. 현재 로빙 임베딩 모델은 384차원이고, StarsAndI가 쓰는 OpenAI 임베딩은 1536차원이다

- 현재 로빙 `skill-embedding` 런타임 설정은 아래와 같다.
  - 모델: `multilingual-MiniLM-L12-v2`
  - 차원: `384`
- 확인 근거:
  - `skill-embedding/.env`
  - `rb8001` 런타임 로그의 `Collection expecting embedding with dimension of 768, got 384`
- 비교 대상으로 본 StarsAndI 코드의 OpenAI 임베딩 경로는 아래와 같다.
  - 모델: `text-embedding-3-small`
  - 차원: `1536`
- 확인 근거:
  - `starsandi/apps/apps/api-py/app/services/recommend.py`
  - 실제 OpenAI 임베딩 API 호출 결과 `dim=1536`

### 11. OpenAI 임베딩 단건 호출 시간은 현재 환경에서 대략 0.2초~3초, 평균 1.8초 수준이다

- StarsAndI가 쓰는 실제 모델 `text-embedding-3-small`로 대표 질문 1건을 3회 호출해 시간을 측정했다.
- 측정 결과:
  - 1회: `2966.1ms`
  - 2회: `2226.3ms`
  - 3회: `234.3ms`
  - 평균: `1808.9ms`
- 따라서 OpenAI 임베딩은 현재 환경에서 단건 기준 대략 `0.2초 ~ 3초`, 보통 `약 2초` 안팎으로 보는 것이 맞다.

### 12. 2,000개 쉬운 문서 기준 인덱싱 시간은 로컬 모델이 더 짧고, OpenAI 모델도 절대 시간이 과도하지는 않다

- 현재 로빙 로컬 임베딩 경로(`384d`) 기준 현실 추정:
  - 쉬운 문서 평균 `0.6초 ~ 2초/문서`
  - `2,000개` 문서: 약 `20분 ~ 67분`
- OpenAI 임베딩 경로(`1536d`) 기준 현실 추정:
  - 네트워크 왕복 포함 평균 `2.5초 ~ 4초/문서`
  - `2,000개` 문서: 약 `83분 ~ 133분`
- 따라서 `2,000개 쉬운 문서` 범위는 두 경로 모두 `몇 시간 이내`에 검증 가능하다.

### 13. OpenAI 임베딩 비용은 2,000개 문서 규모에서는 병목이 아니다

- `text-embedding-3-small`의 현재 공식 가격은 `1M tokens당 $0.02`다.
- 문서당 평균 토큰 수를 가정한 대략 비용:
  - `1,000 tokens x 2,000문서 = 2M tokens` -> 약 `$0.04`
  - `2,000 tokens x 2,000문서 = 4M tokens` -> 약 `$0.08`
  - `5,000 tokens x 2,000문서 = 10M tokens` -> 약 `$0.20`
- 따라서 이번 주제에서 OpenAI 임베딩 선택의 핵심 기준은 비용보다 `품질`, `속도`, `운영 단순성`이다.

### 14. 품질 비교 테스트는 지금 바로 설계 가능한 상태다

- 현재 단계에서 가능한 최소 품질 테스트는 아래 구조다.
  - Company X 질문 `20~50개`를 고정한다.
  - 각 질문에 대해 사람이 `정답 근거 문서`를 1차 지정한다.
  - 같은 문서셋을 `384d 로컬 모델`과 `1536d OpenAI 모델`로 각각 인덱싱한다.
  - 같은 질문셋을 돌려 `정답 문서가 상위 결과에 들어오는지`를 비교한다.
- 이 비교는 아직 답변 생성 LLM 품질이 아니라, `검색 근거 품질`을 먼저 비교하는 테스트다.
- 현재 문제의 본질이 `근거 연결`인 점을 고려하면, 이 단계에서는 생성 답변보다 `retrieval quality`를 먼저 보는 것이 맞다.

### 15. 품질 비교에서 바로 쓸 수 있는 지표는 이미 정리할 수 있다

- `Recall@5`
  - 정답 근거 문서가 상위 5개 안에 들어오는지
- `MRR`
  - 정답 근거 문서가 평균 몇 위에 오는지
- `근거 문단 사용 가능성`
  - 사람이 봤을 때 바로 답변 근거로 쓸 수 있는 청크인지
- `응답 시간`
  - 인덱싱 시간, 검색 시간
- 현재 단계에서 가장 중요한 지표는 `정답률`보다 `근거 일관성`과 `상위 검색 적중률`이다

### 16. 소규모 retrieval 품질 비교 결과, 로컬 384d와 OpenAI 1536d는 현재 표본에서 동률이었다

- 비교 조건:
  - 문서: `옐로펀치X컴퍼니엑스 MOU` 1건, `오늘전통 사업계획서_컴퍼니엑스` 1건
  - 청킹: `skill-rag-file`과 같은 문자 기반 청킹(`1000`, overlap `200`)
  - 총 청크 수:
    - `mou`: `3`
    - `todaytradition`: `38`
  - 질문: `6개`
  - 평가 단위: `문서 수준 top1/top3`, `MRR`
- 비교 모델:
  - 로컬: `multilingual-MiniLM-L12-v2` `384d`
  - OpenAI: `text-embedding-3-small` `1536d`
- 결과 요약:
  - 로컬 `384d`
    - `Top1 = 4/6`
    - `Top3 = 6/6`
    - `MRR = 0.8333`
  - OpenAI `1536d`
    - `Top1 = 4/6`
    - `Top3 = 6/6`
    - `MRR = 0.8333`
- 즉 이 표본에서는 두 모델이 문서 수준 retrieval 성능에서 사실상 동률이었다.

### 17. 질문 유형별로는 두 모델의 강점이 조금 다르게 나타났다

- 로컬 `384d`가 더 잘 맞힌 질문:
  - `오늘전통 사업계획서에서 옐로펀치가 협력기관으로 제시되는 근거`
  - 이 질문에서 로컬은 `todaytradition`을 `Top1`로 올렸고, OpenAI는 `mou`를 `Top1`로 올렸다.
- OpenAI `1536d`가 더 잘 맞힌 질문:
  - `예비창업자 및 초기 창업기업 대상 지원사업 공동 컨소시엄 협력`
  - 이 질문에서 OpenAI는 `mou`를 `Top1`로 올렸고, 로컬은 `todaytradition`을 `Top1`로 올렸다.
- 공통적으로 둘 다 헷갈린 질문:
  - `교육 멘토링 세미나 IR 등 기업 육성 프로그램 운영 참여`
  - 두 모델 모두 `todaytradition`을 `Top1`로 올리고 `mou`를 `2위`로 두었다.

### 18. 현재 표본 기준으로는 차원 수가 곧바로 품질 우위를 보장하지 않았다

- `1536d` OpenAI 모델이 `384d` 로컬 모델보다 무조건 더 낫다는 결과는 나오지 않았다.
- 현재 표본에서는 두 모델이 같은 점수를 냈고, 질문별로 서로 다른 실수를 보였다.
- 따라서 다음 단계에서 모델 선택은 `차원 수`만으로 결정하면 안 된다.

### 19. 현재 단계에서 더 필요한 것은 큰 모델 교체보다 질문셋 확대와 문서군 확대다

- 지금 비교는 `2문서`, `6질문`의 매우 작은 샘플이다.
- 이 표본만으로 최종 모델 결론을 내리기에는 부족하다.
- 그러나 최소한 아래 두 사실은 확인됐다.
  - 로컬 `384d`도 Company X 근거 검색에 충분히 경쟁력 있는 초기 후보다.
  - OpenAI `1536d`는 비용이 낮고 품질 비교 가치가 있지만, 현재 표본에서 압도적 우위를 보이지는 않았다.
- 따라서 다음 계획에서는 먼저 `2,000개 쉬운 문서`와 `20~50개 질문셋`으로 비교 범위를 넓히는 것이 맞다.

## Interpretation

### 1. 아이디어 문서는 유효한 가설이다

- `Company X 내부 문서를 우선 근거로 삼아 답하는 로빙`이라는 아이디어는 헛가설이 아니다.
- 실제 NAS에는 답변 근거가 될 문서가 있고, 그 문서에는 질문과 관련된 표현도 존재한다.
- 따라서 이 아이디어는 `근거를 만들자`가 아니라 `이미 있는 근거를 로빙 답변 경로에 연결하자`로 해석하는 것이 맞다.

### 2. 시나리오 문서의 현재/기대 대비도 실제 상태와 맞는다

- 현재 실제 응답은 `찾아보겠습니다` 수준의 일반 답변이다.
- 기대 시나리오는 `직접 답변 + 근거 문서 + 문단 요약 + 위치 정보`다.
- 이번 조사 결과는 시나리오 문서가 상상적 요구가 아니라, 실제 현재 상태와 분명히 대비되는 목표 상태임을 확인한다.

### 3. 다음 단계의 핵심은 RAG 품질보다 먼저 `색인 경로 + 질문 해석 경로`다

- 지금 부족한 것은 답변 문체가 아니라 연결 구조다.
- 최소한 아래 두 경로가 동시에 생겨야 한다.
  - NAS 원본 -> Company X 전용 RAG 인덱스
  - Company X 질문 -> Company X 전용 문서 검색 의도/실행 경로
- 둘 중 하나라도 빠지면 기대 시나리오는 닫히지 않는다.

### 4. `오늘전통 공동 운영` 답변은 문서 충돌/표현 차이까지 다뤄야 한다

- 사업계획서에는 `협력기관`, `외부 협력체계` 표현이 있고, MOU에는 `프로그램 운영 참여`, `공동 컨소시엄 협력` 표현이 있다.
- 따라서 미래 로빙은 무조건 `같이 운영한다`고 단정하기보다,
  - `오늘전통 사업계획서에서 옐로펀치가 협력기관으로 제시된다`
  - `Company X-옐로펀치 MOU에는 프로그램 운영 참여와 공동 컨소시엄 협력이 명시된다`
  - `문서 표현은 공동 운영/협력 운영/협력기관으로 조금씩 다르다`
  를 함께 답하는 편이 더 정확하다.

### 5. 현재 단계에서 전체 5만여 개를 먼저 넣는 것보다 2천 개 샘플 품질 비교가 더 맞다

- 전체 `52,833개` 경로를 한 번에 인덱싱하는 것은 가능하더라도, 지금 필요한 질문은 `될 수 있는가`보다 `어떤 모델/경로가 더 낫고 실제 근거 검색이 맞는가`다.
- 이미 시간 측정상 `2,000개 쉬운 문서` 범위는 현실적으로 `1~2시간대` 안에서 비교 가능하다.
- 따라서 다음 `plans`는 먼저 `대표 문서군 2,000개 내외 샘플 인덱싱 + 20~50개 질문셋 품질 비교`를 우선 고정하는 것이 맞다.

### 6. 임베딩 모델 선택 기준은 비용보다 검색 품질과 운영 복잡도다

- 비용 차이는 `2,000개` 규모에서는 매우 작다.
- 실제 선택 기준은 아래가 된다.
  - `384d 로컬`: 빠름, 외부 의존 적음, 운영 단순
  - `1536d OpenAI`: 네트워크 의존, 약간 느림, 그러나 품질 우위 가능성 존재
- 즉 다음 계획 단계에서 해야 할 것은 `이론 비교`가 아니라 `같은 질문셋으로 실제 retrieval quality를 비교하는 실험`이다.

### 7. 현재 작은 표본에서는 로컬 384d를 버릴 이유가 없다

- 작은 표본이지만 `Top1`, `Top3`, `MRR`이 OpenAI와 동률이었다.
- 따라서 현재 단계에서 바로 OpenAI 임베딩으로 전면 전환할 근거는 없다.
- 오히려 운영 단순성과 속도를 고려하면, 로컬 `384d`를 기본 후보로 유지한 채 OpenAI `1536d`를 비교군으로 계속 두는 편이 합리적이다.

## Unresolved

1. Company X 소속 사용자 판별 기준
- 어떤 인증 신호로 `Company X 내부 문서 검색 허용 사용자`를 확정할지 아직 정해지지 않았다.

2. Company X 문서의 색인 단위
- 원본 PDF/DOC/HWP를 그대로 청킹할지, 사람이 읽기 쉬운 중간 RAG 포맷으로 정제할지 아직 미정이다.

3. Company X 전용 team/collection 경계
- 현재 `skill-rag-file`은 `team_id` 기반 컬렉션 구조를 쓴다.
- Company X 내부 문서를 어떤 식별자와 어떤 권한 경계로 넣을지 아직 고정되지 않았다.

4. 답변 근거 노출 수준
- 문서명, 문단 요약, 파일 경로, 페이지 위치 중 어디까지 사용자에게 노출할지 아직 정해지지 않았다.

5. 질문 해석 규칙
- `근거 있어?`, `자료 기준으로`, `내부 문서 기준으로` 같은 표현을 별도 의도로 볼지, 일반 질문에 Company X 컨텍스트를 자동 적용할지 아직 미정이다.

6. 샘플 문서셋 구성
- `2,000개 쉬운 문서`를 어떤 기준으로 뽑을지 아직 정해지지 않았다.
- 오늘전통, MOU, 프로그램 소개, 운영안, 보도자료 초안 같은 문서군 우선순위를 먼저 고정해야 한다.

7. OpenAI 1536d와 로컬 384d의 실제 검색 품질 비교 결과
- 현재는 `2문서`, `6질문` 기준 소규모 retrieval quality 비교 결과만 있다.
- 더 큰 문서군과 질문셋에서 같은 경향이 유지되는지는 아직 확인되지 않았다.

## 현재 결론

- 대표 질문에 대한 현재 실제 로빙 답변은 기대 시나리오를 만족하지 못한다.
- 그러나 내부 NAS 원본에는 관련 근거 문서가 실제로 존재한다.
- 현재 실패 원인은 `Company X 근거 없음`이 아니라 `Company X 근거 문서가 런타임 RAG 경로와 연결되지 않음`이다.
- 시간과 비용 조사 결과, `2,000개 쉬운 문서` 규모는 실험 가능한 범위이며 비용도 병목이 아니다.
- 소규모 품질 비교에서는 `384d 로컬`과 `1536d OpenAI`가 동률이었으므로, 현 시점에서 모델 교체 결론을 먼저 내릴 필요는 없다.
- 따라서 다음 단계 `plans`는 `2,000개 샘플 문서셋`, `20~50개 질문셋`, `384d vs 1536d 확장 비교`, `문서 색인`, `권한 경계`, `질문 해석`, `근거답변 형식`을 한 번에 고정하는 계획 문서여야 한다.

## 관련 문서
- [Company X 내부 문서 RAG 응답 아이디어](../ideas/260312_companyx_내부문서_rag_응답_아이디어.md)
- [Company X 내부 문서 근거응답 사용자 시나리오](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)
- [컴퍼니엑스(Company X) 개요](../../book/500_business/560_컴퍼니엑스_개요.md)