71일차 자료 추가(답 제외)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
mcchaeandClaude Opus 5.5 committed
1 parent
505dcd313f
commit
176e195dc2
62 files changed
+6288
No files matched your search
@@ -0,0 +1,343 @@
|
||||
# 71일차 개요 · RAG 기반 검색·응답과 검색 품질 개선
|
||||
|
||||
> 운영·확장 관점의 AI 워크플로우 설계 고도화 · 2026-10-23
|
||||
> 23장 · 각 장은 가로줄(`---`)로 나뉩니다. 1교시에는 1~7장을 보고, 나머지 장은 각 단계를 설명할 때 함께 띄웁니다.
|
||||
> 숫자는 2026-10-18 수업 준비 측정과 2026-10-22 같은 정답으로 다시 돌린 기록입니다.
|
||||
|
||||
| 장 | 범위 |
|
||||
| --- | --- |
|
||||
| 1~7 | 표지 · 목표 · 시간표 · 앞 일차와의 연결 · 왜 RAG인가 · 오늘의 그림 · 오늘의 문서 |
|
||||
| 8~11 | 1단계 · 점수 읽기 · 정답표 · 청크 하나 · 메모리 저장소 |
|
||||
| 12~16 | 2단계 · 발췌로만 · 출처 · 관련도 기준 · 답이 없을 때 · 넘기는 길 |
|
||||
| 17~21 | 3단계 · 지표 셋 · 청크 크기 · 잘린 문장과 섞인 청크 · 질문 다시 쓰기 · 같은 설정 다른 결과 |
|
||||
| 22~23 | 7교시 바이브 코딩 · 정리와 예고 |
|
||||
|
||||
---
|
||||
|
||||
## 1 / 23 · 표지
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
D[("규정 8개")] --> C["청크"] --> V[("벡터 저장소")]
|
||||
Q(["질문"]) --> S["검색"] --> A{{"근거로 답"}} --> O(["답 + 출처"])
|
||||
V --> S
|
||||
classDef g fill:#8A9BA0,stroke:#8A9BA0,color:#fff
|
||||
classDef o fill:#F2A541,stroke:#F2A541,color:#fff
|
||||
classDef t fill:#0F7C80,stroke:#0F7C80,color:#fff
|
||||
classDef d fill:#0F3D3E,stroke:#0F3D3E,color:#fff
|
||||
class D,Q g
|
||||
class C,S o
|
||||
class V,A t
|
||||
class O d
|
||||
```
|
||||
|
||||
**71일차**
|
||||
|
||||
# RAG 기반 검색·응답과 검색 품질 개선
|
||||
|
||||
정답표 · 청크 · 임베딩 · 근거로 답하기 · 답 검사 · doc@1 · answer@1
|
||||
|
||||
<sub>운영·확장 관점의 AI 워크플로우 설계 고도화 · 2026-10-23</sub>
|
||||
|
||||
---
|
||||
|
||||
## 2 / 23 · 오늘 할 수 있게 될 세 가지
|
||||
|
||||
| | 오늘 할 수 있게 될 것 |
|
||||
| :-: | --- |
|
||||
| **①** | 검색 전에 **정답표**를 만들고, 규정 문서를 색인·검색하는 워크플로우를 요청문으로 만든다 |
|
||||
| **②** | 검색한 발췌로만 답하고 출처를 붙이며, 관련 없거나 답이 없으면 **넘긴다** |
|
||||
| **③** | 검색 품질을 **숫자**(doc@1 · answer@1 · answer@3)로 재고, 한 번에 하나씩 바꿔 고친다 |
|
||||
|
||||
---
|
||||
|
||||
## 3 / 23 · 오늘의 시간표
|
||||
|
||||
| ① 1~2교시 | ② 3~4교시 | ③ 5~6교시 | ④ 7~8교시 |
|
||||
| --- | --- | --- | --- |
|
||||
| **1단계** | **2단계** | **3단계** | **바이브 코딩** |
|
||||
| RAG와 색인 | 근거로 답하기 | 검색 품질 | `tdoc` |
|
||||
| Lab 01 정답표 · 색인 · 검색 | Lab 02 출처 · 기준값 · 답 검사 | Lab 03 재기 · 고치기 | 요청서 → SPEC → 만들기 · 발표 |
|
||||
|
||||
> 09:00 시작 · 50분 수업 10분 휴식 · 4교시 뒤 13:00~14:00 점심
|
||||
|
||||
---
|
||||
|
||||
## 4 / 23 · 앞 일차와의 연결
|
||||
|
||||
| 일차 | 그때 | 오늘 이어지는 것 |
|
||||
| --- | --- | --- |
|
||||
| 64 | 지시문에 규칙을 적음 | "발췌로만, 번호로, 모르면 이 문장" |
|
||||
| 67 | FAQ Tool (**낱말**로 찾기), Check answer | 뜻으로 찾기, 답 검사 넷 |
|
||||
| 69 | 검토 답을 못 읽으면 통과로 치지 않음 | 확실하지 않으면 담당자 연결 |
|
||||
| 70 | 계약을 정하고 테스트로 지킴 | 색인 · 검색 · Q&A 계약, 24문항 |
|
||||
| 72 (내일) | 느린 곳 재기 | LLM 없는 길 0.3초 vs LLM 1.8~3.0초 |
|
||||
|
||||
---
|
||||
|
||||
## 5 / 23 · 왜 RAG인가
|
||||
|
||||
| | LLM에 그냥 묻기 | RAG |
|
||||
| --- | --- | --- |
|
||||
| "비밀번호 며칠마다?" | 그럴듯한 숫자 | 우리 규정의 **90일** + `[비밀번호·계정 보안 규정]` |
|
||||
| 규정이 바뀌면 | 모델이 모름 | 문서만 다시 색인 |
|
||||
| 틀렸는지 확인 | 어려움 | 출처를 열어 봄, 코드로 검사 |
|
||||
|
||||
| 다른 방법 | 왜 오늘은 아닌가 |
|
||||
| --- | --- |
|
||||
| 지시문에 규정 전부 | 문서가 많으면 길고, 바뀔 때마다 지시문을 고침 |
|
||||
| 파인튜닝 | 사실을 정확히 외우게 하기 어렵고 출처가 없음 |
|
||||
| Tool로 조회 (67일차) | 낱말이 맞아야 찾음 ("암호" ≠ "비밀번호") |
|
||||
|
||||
---
|
||||
|
||||
## 6 / 23 · 오늘의 그림
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph IDX["색인 my-index"]
|
||||
D[("/docs 8개")] --> C["섹션 청크 25개"] --> E["임베딩"] --> V[("메모리 저장소")]
|
||||
end
|
||||
Q(["질문"]) --> S["가까운 청크 3개<br/>my-search"] --> R{"≥ 0.33?"}
|
||||
R -->|예| L{{"발췌로만 답"}} --> K["답 검사"] --> A(["답 + 출처"])
|
||||
R -->|아니오| H(["담당자 연결"])
|
||||
K -->|실패| H
|
||||
V --> S
|
||||
```
|
||||
|
||||
> 메모리 저장소는 n8n이 재시작되면(push 할 때마다) 지워집니다. `flow.py test`는 케이스 파일의 `before` 칸(명령이 아님)에 적힌 대로 먼저 색인합니다.
|
||||
|
||||
---
|
||||
|
||||
## 7 / 23 · 오늘의 문서 · 규정 8개, 섹션 25개
|
||||
|
||||
| 문서 | 섹션 | 문서 | 섹션 |
|
||||
| --- | --- | --- | --- |
|
||||
| 비밀번호·계정 보안 | 4 | 개인정보 처리 지침 | 3 |
|
||||
| 업무용 장비 지급·반납 | 4 | 원격근무·VPN 이용 | 3 |
|
||||
| 메일·문서 보안 | 3 | 보안 사고 대응 절차 | 2 |
|
||||
| 회의실 이용 | 3 | 소프트웨어 사용 | 3 |
|
||||
|
||||
> 문서 하나가 526~928바이트로 짧고, 모두 `## ` 섹션으로 나뉩니다. 데이터 API `/docs`(71일차 판)에서 가져옵니다.
|
||||
|
||||
---
|
||||
|
||||
## 8 / 23 · 1단계 · 점수 읽기 (섹션 청크, 실측)
|
||||
|
||||
| 질문 | 1등 | 2등 | 3등 |
|
||||
| --- | --- | --- | --- |
|
||||
| 비밀번호는 몇 자 이상? | 만들기 **0.748** | 변경 주기 0.54 | 잠금 0.484 |
|
||||
| 암호를 얼마나 자주 바꿔야 해? | 변경 주기 **0.576** | 만들기 0.512 | 다단계 인증 0.456 |
|
||||
| 컴퓨터가 바이러스에 걸린 것 같아요 | 악성코드 **0.478** | 피싱 0.357 | 재택 보안 0.249 |
|
||||
| 오늘 점심 메뉴 추천해줘 | (규정 아무거나) **0.202** | | |
|
||||
|
||||
> "암호"는 규정에 없는 낱말인데 "변경 주기"가 1등 → **뜻**으로 찾았습니다. 점수는 확률이 아니라 **순서**의 근거입니다.
|
||||
|
||||
---
|
||||
|
||||
## 9 / 23 · 1단계 · 정답표가 먼저
|
||||
|
||||
| 질문 | 문서 | 답 문구 |
|
||||
| --- | --- | --- |
|
||||
| 비밀번호는 몇 자 이상? | `password-policy` | 12자 |
|
||||
| 암호를 얼마나 자주 바꿔야 해? | `password-policy` | 90일 |
|
||||
| 회사를 그만두면 노트북은? | `device-issue-return` | 5영업일 |
|
||||
| 연차 휴가는 며칠? | **없음** | — |
|
||||
|
||||
> 검색 결과를 보고 "그럴듯하다"고 판단하지 않습니다. 먼저 정답을 정해야 **셀 수** 있습니다. 정답표도 틀립니다: "윈도우 업데이트"는 규정에 없었습니다.
|
||||
|
||||
---
|
||||
|
||||
## 10 / 23 · 1단계 · 청크 하나의 모양
|
||||
|
||||
```text
|
||||
글: 비밀번호·계정 보안 규정 ← 문서 제목을 앞에
|
||||
## 2. 변경 주기
|
||||
- 비밀번호는 90일마다 바꾼다. …
|
||||
메타데이터: source · title (과제: section) ← 출처는 여기서
|
||||
벡터: 3,072차원 (text-embedding-3-large)
|
||||
```
|
||||
|
||||
| | 결과 (실측) |
|
||||
| --- | --- |
|
||||
| `lab01` | 6/6 |
|
||||
| 섹션 제목까지 출처 (`lab01-challenge`) | 예제 2/4 → 4/4 |
|
||||
|
||||
> 예제는 섹션 제목이 **글 안에는** 있지만 **칸으로는** 없어서 2/4였습니다.
|
||||
|
||||
---
|
||||
|
||||
## 11 / 23 · 1단계 · 메모리 저장소의 한살이
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P["push"] --> R["n8n 재시작"] --> E[("빔")] -->|"call my-index · test(before 칸)"| I[("청크 25개")] --> S["검색"]
|
||||
```
|
||||
|
||||
| | 시간 (실측) |
|
||||
| --- | --- |
|
||||
| push 직후 첫 색인 | 3.8초 |
|
||||
| 다시 색인 (`test`가 `before` 칸으로) | 0.4~2.2초 |
|
||||
| 검색 한 번 | 0.2~0.9초 |
|
||||
|
||||
> 운영에서는 n8n 밖의 벡터 DB(재시작에도 남음, 바뀐 문서만 다시 색인). 흐름은 같습니다.
|
||||
|
||||
---
|
||||
|
||||
## 12 / 23 · 2단계 · 발췌로만 답하기
|
||||
|
||||
```text
|
||||
질문: 암호를 얼마나 자주 바꿔야 해?
|
||||
규정 발췌:
|
||||
[1] 비밀번호·계정 보안 규정 ## 2. 변경 주기 - 비밀번호는 90일마다 바꾼다. …
|
||||
[2] … ## 1. 비밀번호 만들기 …
|
||||
[3] … ## 4. 다단계 인증 …
|
||||
```
|
||||
|
||||
→ "암호는 90일마다 변경해야 하며, … [비밀번호·계정 보안 규정]" (`lab02` 6/6)
|
||||
|
||||
> 틀린 전제("30일마다 바꾸면 되죠?")에도 "30일이 아니라 90일"이라고 답했습니다. 질문이 아니라 **발췌**가 기준입니다.
|
||||
|
||||
---
|
||||
|
||||
## 13 / 23 · 2단계 · 번호로 출처, `sources`와 `cited`
|
||||
|
||||
| 질문 | `sources` (찾은 문서) | `cited` (인용한 문서) |
|
||||
| --- | --- | --- |
|
||||
| 생성형 AI에 고객 자료를 넣어도? | 소프트웨어, 개인정보 | 소프트웨어 |
|
||||
| 비밀번호를 잊어버리면 어디서 바꿔요? | 비밀번호 | **없음** |
|
||||
|
||||
> LLM은 `[번호]`만 쓰고, 번호 → 제목은 **코드**가 바꿉니다. 찾았는데 인용하지 않았다면 답이 발췌를 쓰지 않은 것입니다.
|
||||
|
||||
---
|
||||
|
||||
## 14 / 23 · 2단계 · 관련도 기준 0.33
|
||||
|
||||
| 규정 질문 5개 | 규정 밖 5개 (점심 · 연차 · 영화 · 맛집 · 연봉) |
|
||||
| --- | --- |
|
||||
| 0.464 ~ 0.616 | 0.202 ~ 0.261 |
|
||||
|
||||
| 기준을 올리면 | 기준을 낮추면 |
|
||||
| --- | --- |
|
||||
| 진짜 질문도 넘김 (0.47 → "퇴사 노트북" 0.464) | 엉뚱한 질문에 답을 씀 |
|
||||
|
||||
> 답이 **있는데** 0.267인 질문도 있습니다 ("공짜 프로그램은 그냥 써도 되죠?"). 기준값은 모델마다 두 무리를 재서 정합니다.
|
||||
|
||||
---
|
||||
|
||||
## 15 / 23 · 2단계 · 점수는 높은데 답이 없을 때
|
||||
|
||||
| 질문 | 점수 | 기준값만 쓴 결과 |
|
||||
| --- | --- | --- |
|
||||
| VPN 접속 속도가 느리면? | 0.463 | `자동 답변`: "…언급하고 있지 않습니다" |
|
||||
| 노트북 사양은? | 0.379 | `자동 답변`: "…포함되어 있지 않습니다" + **출처 3개** |
|
||||
| 비밀번호를 잊어버리면? | 0.551 | `자동 답변`: "규정에서 답을 찾지 못했습니다" |
|
||||
|
||||
> 기준값으로는 못 거릅니다. **답 검사**(모른다고 했나 · 인용 · 근거 겹침 · 숫자)로 넘깁니다: `lab02-challenge` 2/8 → 8/8 (`--repeat 3` 24/24).
|
||||
|
||||
---
|
||||
|
||||
## 16 / 23 · 2단계 · 넘기는 길 세 갈래
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
T{"기준 통과?"} -->|아니오| H1(["담당자 연결<br/>규정에 없음"])
|
||||
T -->|예| K{"답 검사 통과?"} -->|예| A(["자동 답변 + 출처"])
|
||||
K -->|아니오| H2(["담당자 연결<br/>규정이 모자람 + draft"])
|
||||
```
|
||||
|
||||
> 두 담당자 연결은 **말과 넘기는 것이 다릅니다.** 뒤쪽이 쌓이는 곳(VPN 속도, 노트북 사양 …)이 규정을 보완할 곳입니다.
|
||||
|
||||
---
|
||||
|
||||
## 17 / 23 · 3단계 · 지표 셋
|
||||
|
||||
| 지표 | 묻는 것 |
|
||||
| --- | --- |
|
||||
| doc@1 | 1등이 맞는 **문서**인가 |
|
||||
| answer@1 | 1등에 **답 문구**가 있나 |
|
||||
| answer@3 | 3등 안에 답 문구가 있나 (LLM에 3개를 줌) |
|
||||
|
||||
| answer@1에서 틀린 예 | 1등 (답 없음) | 2등 (답 있음) |
|
||||
| --- | --- | --- |
|
||||
| 회사를 그만두면 노트북은? | 지급과 교체 0.464 | 반납 0.45 |
|
||||
|
||||
> doc@1 ✔ · answer@1 ✘ = 맞는 문서의 **다른 섹션**이 1등.
|
||||
|
||||
---
|
||||
|
||||
## 18 / 23 · 3단계 · 청크 크기 (24문항)
|
||||
|
||||
| 설정 | 청크 | doc@1 | answer@1 | answer@3 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 섹션 | 25 | 24 | 22 | 24 |
|
||||
| 200자 | 20 | 24 | 20 | 24 |
|
||||
| 400자 | 12 | 22 | 22 | 24 |
|
||||
|
||||
> 한 번에 **하나만** 바꿉니다. `call my-index` + `test --no-before`. 우리 문서에서는 섹션이 가장 좋았고, 3개를 주면(answer@3) 차이가 줄었습니다.
|
||||
|
||||
---
|
||||
|
||||
## 19 / 23 · 3단계 · 잘린 문장과 섞인 청크
|
||||
|
||||
| 설정 | 일어난 일 |
|
||||
| --- | --- |
|
||||
| 200자 | "만료 **30일 전부터** … 새 인증서를 \| 신청한다" — 문장 한가운데가 잘려 답 문구가 앞 청크로. 섹션 이름도 어긋남 |
|
||||
| 400자 | 원격근무 문서의 섹션 셋이 모두 한 청크에 → "화면 잠금" 질문의 1등이 **0.241** 회의실 규정, 답이 든 청크는 2등 0.236 (섹션 색인에서는 0.354로 1등) |
|
||||
|
||||
> 같은 22점이라도 **틀린 질문이 다릅니다.** 표에 틀린 질문까지 적습니다.
|
||||
|
||||
---
|
||||
|
||||
## 20 / 23 · 3단계 · 질문 다시 쓰기의 득실
|
||||
|
||||
| 질문 | 다시 쓴 검색어 | 결과 |
|
||||
| --- | --- | --- |
|
||||
| 챗GPT에 회의록 붙여 넣어도 돼요? | 생성형 AI 서비스에 회의록 데이터 입력 정책 | ✘ 회의실 → ✔ 소프트웨어 |
|
||||
| 고객 명단 엑셀을 개인 메일로 … | 고객 명단 엑셀 외부로 보내기 및 보안 정책 | ✘ 보안 사고 → ✔ 메일·문서 |
|
||||
| 모르는 프로그램이 자꾸 저절로 떠요 | 알 수 없는 프로그램 자동 실행 정책 | ✔ 보안 사고 → ✘ **소프트웨어** |
|
||||
|
||||
| | 다시 쓰기 없이 | 다시 쓰기 |
|
||||
| --- | --- | --- |
|
||||
| 어려운 질문 8개 | 6/8 | 7/8 |
|
||||
| 검색 시간 | 0.2~0.5초 | 0.9~2.0초 |
|
||||
|
||||
> 고치면 다른 것이 깨질 수 있습니다. 좋아진 것과 나빠진 것을 **함께** 잽니다.
|
||||
|
||||
---
|
||||
|
||||
## 21 / 23 · 3단계 · 같은 설정, 다른 결과
|
||||
|
||||
| | 10/18 | 10/22 |
|
||||
| --- | --- | --- |
|
||||
| "고객 정보가 밖으로 샌 것 같아요" 다시 쓴 검색어 | 유출 **대응 방안** | 유출 **방지 정책** |
|
||||
| 1등 | 3. 유출 대응 ✔ | 2. 이용과 보관 ✘ |
|
||||
| 24문항 answer@1 | 24 | 23 |
|
||||
|
||||
> 검색 앞에 LLM이 있으면 검색도 매번 달라집니다. `--repeat`으로 재고 **범위**로 적습니다. LLM이 없는 섹션 검색은 두 날 모두 22였습니다.
|
||||
|
||||
---
|
||||
|
||||
## 22 / 23 · 7교시 · 바이브 코딩 `tdoc`
|
||||
|
||||
```text
|
||||
$ tdoc ~/aio-01d4-stu/Lecture
|
||||
질문: [메모리 저장소는 언제 지워져요?]
|
||||
답: n8n이 재시작되면 지워집니다 [1] …
|
||||
근거: [1] 0.xx Lecture/71/01-STAGE1-RAG-AND-INDEX.md · 5. 메모리 저장소
|
||||
```
|
||||
|
||||
- **요청서(`VIBE-REQ-TDOC`)부터** 읽고 `SPEC.md`를 에이전트 없이 10분 → VIBE-Q와 비교 → 단계별로 만들기
|
||||
- 내 md 문서를 SQLite에 색인(바뀐 파일만)하고 근거와 함께 답하는 TUI, 설정 비교(`tdoc eval`)
|
||||
|
||||
---
|
||||
|
||||
## 23 / 23 · 정리와 72일차 예고
|
||||
|
||||
| 오늘 | 한 줄 |
|
||||
| --- | --- |
|
||||
| 1단계 | 정답표가 먼저, 청크는 뜻 단위로, 메타데이터가 출처, 메모리 저장소는 재시작에 지워짐 |
|
||||
| 2단계 | 발췌로만 답하고 번호로 출처, 기준값은 엉뚱한 질문을, 답 검사는 답 없는 질문을 |
|
||||
| 3단계 | 지표 셋으로 재고, 하나씩 바꾸고, 틀린 질문과 나빠진 것도 적는다 |
|
||||
|
||||
- 72일차: **Workflow 실행 흐름 최적화** — 느린 곳을 재고, 규칙 먼저·캐시·LLM 호출 줄이기로 빠르게, 고장 나도 정해진 답을 · 바이브 코딩 `tbench`
|
||||
@@ -0,0 +1,86 @@
|
||||
# 71일차 실습 준비 · 수업 전에 미리 해 두면 좋은 것
|
||||
|
||||
- 수업일: 2026-10-23 (71일차) · RAG 기반 검색·응답 Workflow와 검색 품질 개선
|
||||
- 준비 시간: 약 10분 (70일차 준비를 했다면 1·2절만)
|
||||
- 먼저 WSL에서 `cd ~/aio-01d4-stu && git pull`로 오늘 자료를 받습니다 (수강생 저장소: https://gl.isitsoft.kr/publicproj/aio-01d4-stu).
|
||||
- **수업 전날까지** 1~2절을 끝내 주세요.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. n8n · 데이터 API 켜기<br/>(71일차 판)"] --> B["2. doctor<br/>ready"] --> C["3. 미리 읽기"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. n8n과 데이터 API 켜기 (전날 필수, 3분)
|
||||
|
||||
오늘은 **71일차 판 데이터 API**(67일차 + 규정 문서 `/docs`)를 씁니다. 67일차 데이터 API를 켜 두었다면 이 폴더에서 다시 만들면 바뀝니다 (같은 이름이라 하나만 돕니다).
|
||||
|
||||
```bash
|
||||
sudo systemctl disable --now ollama 2>/dev/null # WSL에 설치한 Ollama가 있으면 끄고 자동 시작도 끔
|
||||
cd ~/aio-01d4-stu/Last3Mon/65/n8n
|
||||
docker compose rm -sf ollama # Ollama 컨테이너가 있으면 지움 (없으면 그냥 지나감)
|
||||
docker compose start
|
||||
cd ~/aio-01d4-stu/Last3Mon/71/data-api
|
||||
docker compose up -d --force-recreate
|
||||
curl -s localhost:8800/docs | head -c 120 # {"docs": [{"name": "device-issue-return", ...
|
||||
```
|
||||
|
||||
- **66일차부터 LLM은 OpenAI API 키(`Last3Mon/.env`, Credential `OpenAI (.env)`)만 씁니다.** Ollama는 쓰지 않으므로 위처럼 꺼서 메모리를 아낍니다. 다음 날부터는 같은 명령을 그대로 써도 됩니다.
|
||||
- `network day65-n8n_default not found` → n8n이 켜져 있지 않음. 위 n8n 부분부터 다시.
|
||||
- `.../day65-n8n/compose.yml: no such file or directory` → 홈이 아닌 곳에 설치함. `Last3Mon/65/n8n/.env`에 `N8N_HOME=<설치 폴더>` ([67일차 준비](../67/00-DAY67-PREP.md) 1절).
|
||||
|
||||
## 2. 준비 확인 (전날 필수, 2분)
|
||||
|
||||
```bash
|
||||
cd ~/aio-01d4-stu/Last3Mon/71
|
||||
uv run tools/flow.py doctor
|
||||
```
|
||||
|
||||
```text
|
||||
✔ n8n install folder /home/<사용자>/day65-n8n
|
||||
✔ n8n container day65-n8n-n8n-1
|
||||
✔ n8n http://localhost:5678
|
||||
✔ data API http://localhost:8800
|
||||
✔ policy documents /docs (8)
|
||||
✔ n8n → http://data-api:8800
|
||||
✔ credential 'OpenAI (.env)' (openAiCourse0001)
|
||||
✔ node catalog (for check)
|
||||
✔ CLI coding agent: codex, claude
|
||||
ready
|
||||
```
|
||||
|
||||
| ✘ 항목 | 할 일 |
|
||||
| --- | --- |
|
||||
| n8n container · data API | 1절 |
|
||||
| policy documents /docs | 데이터 API가 예전 판 → 1절 `--force-recreate` |
|
||||
| credential | `cd ~/aio-01d4-stu/Last3Mon/65/n8n && bash register-credentials.sh` |
|
||||
| CLI coding agent | [67일차 준비](../67/00-DAY67-PREP.md) 2절 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 미리 읽어 오면 좋은 내용 (선택, 약 5분)
|
||||
|
||||
### 3.1 LLM은 우리 회사 규정을 모른다
|
||||
|
||||
"비밀번호는 며칠마다 바꿔야 하나요?"를 LLM에게 그냥 물으면 그럴듯한 숫자를 말합니다. 우리 규정(90일)을 답하게 하려면, 질문할 때마다 **규정에서 관련 부분을 찾아** LLM에게 같이 주어야 합니다. 이것이 RAG입니다.
|
||||
|
||||
### 3.2 용어
|
||||
|
||||
| 용어 | 한 줄 설명 |
|
||||
| --- | --- |
|
||||
| RAG | 검색(Retrieval)한 문서를 붙여(Augmented) 답을 만든다(Generation) |
|
||||
| 청크 | 문서를 검색 단위로 나눈 조각 (오늘은 섹션 하나) |
|
||||
| 임베딩 | 글의 뜻을 숫자 목록(벡터)으로 바꾼 것. 뜻이 가까우면 숫자도 가깝다 |
|
||||
| 벡터 저장소 | 청크와 그 임베딩을 저장하고 가까운 것을 찾아 주는 곳 (오늘은 n8n 메모리) |
|
||||
| doc@1 · answer@1 | 1등 청크가 맞는 문서인가 · 답 문구를 담고 있나 (검색 품질 지표) |
|
||||
|
||||
## 4. 당일 준비물
|
||||
|
||||
- 충전된 노트북과 충전기, WSL의 Docker, Windows Terminal(WSL) 창 **두 개**, 웹 브라우저
|
||||
- 7교시 `tdoc`에 쓸 내 md 문서 폴더 (없으면 이 과정의 `Lecture/` 폴더를 씀)
|
||||
|
||||
## 확인
|
||||
|
||||
- [ ] `curl -s localhost:8800/docs`에 규정 8개가 보인다
|
||||
- [ ] `uv run tools/flow.py doctor` → 마지막 줄 `ready`
|
||||
@@ -0,0 +1,359 @@
|
||||
# 1단계 · RAG와 색인
|
||||
|
||||
- 교시: 1~2교시 (09:00~10:50) · 1교시 강의(개요 포함) 약 40분, 2교시 Lab 01
|
||||
- 실습: [Lab 01](../../Last3Mon/71/LAB-01-Q-INDEX-AND-SEARCH.md)
|
||||
- 이 단계가 끝나면: RAG의 두 흐름(색인 · 질문)을 설명하고, 검색 전에 정답표를 만들고, 규정 문서를 색인·검색하는 n8n 워크플로우를 요청문으로 만들 수 있다.
|
||||
- 이 교안의 숫자: 2026-10-18 수업 준비 측정, 2026-10-22 같은 정답으로 다시 돌린 기록([Last3Mon/71/answers](../../Last3Mon/71/answers/LAB-TEST-RESULT.md), 수업 뒤 공개)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 왜 RAG인가"] --> B["2. 임베딩과<br/>가깝다는 것"] --> C["3. 정답표 먼저"] --> D["4. 청크 · 메타데이터"] --> E["5. 메모리 저장소"] --> F["6. 요청문으로"]
|
||||
```
|
||||
|
||||
| 절 | 말하는 시간 (예) | 띄울 것 |
|
||||
| --- | --- | --- |
|
||||
| 1. 왜 RAG인가 | 7분 | 1절 표 · 그림 |
|
||||
| 2. 임베딩과 가깝다는 것 | 8분 | 실측 점수 표 |
|
||||
| 3. 정답표 먼저 | 7분 | 정답표 · 질문 종류 |
|
||||
| 4. 청크 · 메타데이터 | 8분 | 규정 8개 표 · 청크 하나 |
|
||||
| 5. 메모리 저장소 | 5분 | 한살이 그림 |
|
||||
| 6. 요청문으로 · 확인 질문 | 5분 | 요청문 예 |
|
||||
|
||||
## 1. 왜 RAG인가
|
||||
|
||||
### 1.1 LLM이 우리 회사 일을 못 하는 세 가지 까닭
|
||||
|
||||
| 까닭 | 예 | 결과 |
|
||||
| --- | --- | --- |
|
||||
| **모른다** | 우리 회사 비밀번호 규정은 학습한 적이 없음 | "보통 90일입니다"처럼 **그럴듯한 일반론** |
|
||||
| **오래됐다** | 규정이 지난주에 바뀜 | 바뀐 것을 모름. 모델을 다시 학습시킬 수도 없음 |
|
||||
| **출처가 없다** | 답이 맞는지 사람이 확인할 곳이 없음 | 틀려도 모름 (가장 위험) |
|
||||
|
||||
LLM은 우리 회사 규정을 모릅니다. "비밀번호는 며칠마다 바꿔요?"에 그럴듯한 숫자를 말할 뿐입니다. 그 숫자가 우연히 맞아도, **왜 맞는지**를 보여 줄 수 없습니다.
|
||||
|
||||
### 1.2 우리 문서를 LLM에게 알려 주는 네 가지 방법
|
||||
|
||||
| 방법 | 어떻게 | 좋은 점 | 한계 | 이 과정에서 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 지시문에 모두 넣기 | 규정 전문을 system 메시지에 | 가장 쉬움 | 문서가 많으면 길어지고(비용 · 시간), 바뀔 때마다 지시문을 고침 | 64일차 공지 지시문 |
|
||||
| 파인튜닝 | 우리 문서로 모델을 더 학습 | 말투 · 형식에 강함 | 사실을 정확히 외우게 하기 어렵고, 바뀔 때마다 다시 학습, 출처 없음 | 하지 않음 |
|
||||
| Tool로 조회 | LLM이 "FAQ 찾기" Tool을 부름 | 정해진 질의(번호 · 이름)에 정확 | 낱말이 맞아야 찾음 | 67일차 FAQ Tool |
|
||||
| **RAG** | 질문할 때마다 문서에서 **관련 부분만 찾아** 함께 줌 | 문서가 바뀌면 다시 색인만, **출처**가 남음 | 찾는 것이 틀리면 답도 틀림 | **오늘** |
|
||||
|
||||
**RAG**(Retrieval-Augmented Generation, 검색 증강 생성)는 질문할 때마다 규정에서 **관련 부분만 찾아** LLM에게 같이 주고, 그 부분으로만 답하게 합니다. 이름 그대로 **검색(Retrieval)이 생성(Generation)을 돕습니다.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph 색인["색인 (문서가 바뀔 때)"]
|
||||
D[("문서")] --> C["청크로 나누기"] --> E["임베딩"] --> V[("벡터 저장소")]
|
||||
end
|
||||
subgraph 질문["질문할 때마다"]
|
||||
Q(["질문"]) --> QE["질문 임베딩"] --> S["가까운 청크 k개"] --> L{{"그 청크로만 답"}}
|
||||
end
|
||||
V --> S
|
||||
```
|
||||
|
||||
- 색인은 **가끔**(문서가 바뀔 때), 질문은 **매번**. 두 흐름은 다른 워크플로우입니다 (오늘 `my-index`, `my-search`).
|
||||
- 오늘 1단계는 **찾기까지**만 합니다. 답을 쓰는 것은 2단계입니다. 찾는 것이 틀리면 아무리 좋은 LLM도 맞는 답을 쓸 수 없기 때문에, 찾기를 따로 재고 확인합니다.
|
||||
|
||||
### 1.3 67일차 FAQ 검색과 무엇이 다른가
|
||||
|
||||
| | 67일차 FAQ 검색 | 오늘 RAG |
|
||||
| --- | --- | --- |
|
||||
| 찾는 법 | 낱말이 겹치나 (`keywords`) | **뜻**이 가까운가 (임베딩) |
|
||||
| "암호를 바꿔야 해?" | "암호"가 키워드에 없으면 못 찾음 | "비밀번호" 섹션을 찾음 (실측 아래 2절) |
|
||||
| 찾는 단위 | FAQ 한 개 | 문서의 한 섹션 (청크) |
|
||||
| 준비 | 사람이 FAQ마다 키워드를 적음 | 문서를 그대로 색인 |
|
||||
| 틀리는 방식 | 못 찾음 (0개) | **언제나 무언가를 찾음** (엉뚱한 것도) |
|
||||
|
||||
마지막 줄이 오늘 하루의 숙제입니다. 낱말 검색은 못 찾으면 "없음"이라고 하지만, 뜻 검색은 점심 메뉴를 물어도 가장 가까운 규정 3개를 돌려줍니다. 2단계의 관련도 기준과 답 검사가 이것 때문에 필요합니다.
|
||||
|
||||
## 2. 임베딩과 "가깝다"는 것
|
||||
|
||||
### 2.1 임베딩은 글을 숫자 목록으로
|
||||
|
||||
**임베딩**은 글 한 덩어리를 숫자 목록(벡터) 하나로 바꾸는 것입니다. 오늘 쓰는 `text-embedding-3-large`는 글 하나를 **3,072차원** 벡터(숫자 3,072개짜리 목록)로 바꿉니다 (모델 기본값). 뜻이 비슷한 글은 비슷한 숫자 목록이 되도록 학습된 모델입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["암호를 얼마나 자주<br/>바꿔야 해?"] --> EA["[0.01, -0.03, …]<br/>3,072차원"]
|
||||
B["## 2. 변경 주기<br/>비밀번호는 90일마다…"] --> EB["[0.02, -0.02, …]<br/>3,072차원"]
|
||||
EA --> S{{"얼마나 같은 방향?<br/>(코사인 유사도)"}}
|
||||
EB --> S
|
||||
S --> R["0.576"]
|
||||
```
|
||||
|
||||
- 숫자 하나하나에 뜻이 있는 것은 아닙니다. **두 목록이 얼마나 같은 방향을 가리키는지**(코사인 유사도)만 씁니다. 그림의 숫자 목록은 모양을 보여 주는 예이고, 0.576은 실제로 잰 점수입니다.
|
||||
|
||||
### 2.2 왜 3,072차원인가
|
||||
|
||||
3,072차원은 벡터가 숫자 몇 개로 되어 있는지(**차원 수**)입니다. 글이 섹션 하나든 질문 한 줄이든, 이 모델은 늘 3,072차원 벡터 하나를 돌려줍니다.
|
||||
|
||||
| 물음 | 답 |
|
||||
| --- | --- |
|
||||
| 왜 하필 3,072차원? | 데이터에서 나온 값이 아니라 **모델을 만들 때 정한 크기**입니다. 같은 회사의 작은 모델 `text-embedding-3-small`은 1,536차원. 많을수록 뜻의 미묘한 차이를 더 담을 수 있지만, 저장 공간과 계산이 늘어납니다 |
|
||||
| 숫자 하나는 무슨 뜻? | 3,072차원 공간의 **좌표**입니다. 지도에서 (위도, 경도) 두 숫자로 위치를 나타내듯, 글 하나를 3,072차원 공간의 한 점으로 나타냅니다. 다만 각 축에 사람이 읽을 뜻("3번째 = 보안 정도")은 없습니다. 모델이 학습하며 스스로 정한 축입니다 |
|
||||
| 질문과 청크를 다른 모델로? | 안 됩니다. 차원 수가 다르면 비교가 안 되고, 같아도 모델이 다르면 공간이 달라 점수가 의미 없습니다. **모델을 바꾸면 전부 다시 색인**하고 관련도 기준값도 다시 잽니다 |
|
||||
| 저장 크기는? | 숫자 하나를 보통 4바이트로 저장하면 청크 하나에 약 12KB. 오늘 섹션 청크 25개면 약 300KB로 작지만, 수십만 청크면 GB 단위가 됩니다. 7교시 `tdoc`이 SQLite에 저장하는 것이 이 숫자 목록입니다 |
|
||||
| 줄일 수 있나? | text-embedding-3 모델은 요청할 때 `dimensions`(예: 256, 1024)로 더 짧은 벡터를 받을 수 있습니다. 가볍고 빠르지만 품질이 조금 떨어질 수 있습니다 (오늘은 쓰지 않았고 재지도 않음) |
|
||||
- n8n의 메모리 저장소는 이 점수를 0~1로 돌려줍니다. 클수록 가깝습니다.
|
||||
|
||||
### 2.3 실제로 잰 점수 읽기 (섹션 청크 25개, 2026-10-22)
|
||||
|
||||
| 질문 | 1등 | 2등 | 3등 |
|
||||
| --- | --- | --- | --- |
|
||||
| 비밀번호는 몇 자 이상이어야 하나요? | 비밀번호 · 1. 만들기 **0.748** | 비밀번호 · 2. 변경 주기 0.54 | 비밀번호 · 3. 잠금 0.484 |
|
||||
| 암호를 얼마나 자주 바꿔야 해? | 비밀번호 · 2. 변경 주기 **0.576** | 비밀번호 · 1. 만들기 0.512 | 비밀번호 · 4. 다단계 인증 0.456 |
|
||||
| 첨부 파일이 너무 커서 메일이 안 보내져요 | 메일 · 2. 첨부 파일 **0.616** | 메일 · 1. 메일함 0.455 | 보안 사고 · 1. 피싱 메일 0.335 |
|
||||
| 컴퓨터가 바이러스에 걸린 것 같아요 | 보안 사고 · 2. 악성코드 **0.478** | 보안 사고 · 1. 피싱 0.357 | 원격근무 · 3. 재택 보안 0.249 |
|
||||
|
||||
`top_k: 5`로 같은 바이러스 질문을 물으면 4등 0.246(비밀번호 · 잠금), 5등 0.241(소프트웨어 · 설치)이 더 나옵니다.
|
||||
|
||||
읽는 법:
|
||||
|
||||
1. **"암호"는 규정에 없는 낱말**입니다 (규정은 "비밀번호"). 그래도 1등이 "2. 변경 주기"입니다 → 뜻으로 찾았습니다.
|
||||
2. 점수는 **확률이나 퍼센트가 아닙니다.** 0.478은 "47.8% 맞음"이 아니라, 같은 질문의 다른 청크보다 가깝다는 **순서**의 근거입니다. 질문마다 1등 점수가 0.478~0.748로 다릅니다.
|
||||
3. 1등과 2등의 **차이**도 봅니다. 바이러스 질문은 1등 0.478, 2등 0.357 → 1등이 뚜렷합니다. 3등 이하는 0.25 근처로 모두 비슷합니다 → "관련 없는 것들의 점수대"입니다.
|
||||
4. 점심 메뉴처럼 규정과 상관없는 질문의 1등은 0.202였습니다. 이 "관련 없는 점수대"를 2단계에서 기준값으로 씁니다.
|
||||
|
||||
### 2.4 같은 질문인데 점수가 조금 다르다
|
||||
|
||||
같은 질문 "비밀번호를 잊어버리면 어디서 바꿔요?"의 1등 점수가 한 실행에서는 0.551, 다른 실행에서는 0.55였습니다 ("보안 교육" 질문도 0.352와 0.353). 임베딩도 셋째 자리에서 조금씩 흔들립니다. 그래서 기준값을 어떤 질문의 점수 바로 옆(예: "보안 교육"이 0.352~0.353이니 0.353)에 두지 않습니다. 그러면 같은 질문이 실행마다 통과했다 걸렸다 합니다. 두 무리 사이 **한가운데**에 여유 있게 둡니다 (오늘 0.33: 규정 밖 최고 0.261, 규정 질문 최저 0.464, 2단계 3절).
|
||||
|
||||
## 3. 정답표가 먼저
|
||||
|
||||
### 3.1 검색을 만들기 전에 사람이 정답을 정한다
|
||||
|
||||
| 질문 | 답이 있는 문서 | 섹션 | 답 문구 |
|
||||
| --- | --- | --- | --- |
|
||||
| 비밀번호는 몇 자 이상이어야 하나요? | `password-policy` | 1. 비밀번호 만들기 | 12자 |
|
||||
| 암호를 얼마나 자주 바꿔야 해? | `password-policy` | 2. 변경 주기 | 90일 |
|
||||
| 회사를 그만두면 노트북은 언제까지 돌려줘야 하나요? | `device-issue-return` | 3. 반납 | 5영업일 |
|
||||
| 연차 휴가는 며칠이에요? | **없음** | — | — |
|
||||
|
||||
- 정답표가 있어야 검색이 맞았는지 **숫자로** 셉니다 (3단계에서 24문항).
|
||||
- 답이 **없는** 질문도 정답표에 넣습니다. 검색은 언제나 무언가를 돌려주기 때문입니다 (1.3절 마지막 줄).
|
||||
- 정답표 없이 검색 결과를 보면, 나온 것이 그럴듯해 보여서 "잘 되네요"가 됩니다. **결과를 보기 전에** 써야 합니다.
|
||||
|
||||
### 3.2 질문을 고르는 법: 네 종류를 섞는다
|
||||
|
||||
| 종류 | 예 | 무엇을 시험하나 |
|
||||
| --- | --- | --- |
|
||||
| 규정 낱말 그대로 | 비밀번호는 몇 자 이상? | 기본이 되는가 |
|
||||
| 직원 말투 · 다른 낱말 | 암호를 얼마나 자주 바꿔야 해? / 회사를 그만두면 | 뜻으로 찾는가 |
|
||||
| 규정에 답이 없음 | 연차 휴가는 며칠? / 노트북 사양은? | 모를 때 넘기는가 (2단계) |
|
||||
| 틀린 전제 | 비밀번호는 30일마다 바꾸면 되죠? | 질문이 아니라 규정을 따르는가 (2단계) |
|
||||
|
||||
오늘 Lab의 24문항(`cases/retrieval-*.json`)은 규정 8개에서 2~4개씩, 낱말 그대로와 다른 낱말을 섞어 만들었습니다.
|
||||
|
||||
### 3.3 정답표도 틀린다
|
||||
|
||||
오후 **Lab 03 과제**에서 쓰는 "어려운 질문" 8개를 수업 준비 때 강사가 처음 만들 때, "윈도우 업데이트 안 하고 미루면 안 돼요?"의 기대 문서를 `security-incident`로 적었습니다. 테스트는 실패했습니다 (1등 `software-usage` 0.309, 다시 돌려 0.324). 규정을 다시 열어 보니 윈도우 업데이트 이야기는 **어디에도 없었습니다.** 검색이 틀린 것이 아니라 **정답표가 틀렸습니다.**
|
||||
|
||||
그 뒤에 한 일:
|
||||
|
||||
| 순서 | 한 일 | 결과 |
|
||||
| --- | --- | --- |
|
||||
| ① | 이 질문이 든 어려운 질문 8개를 두 번 돌림 | 두 번 다 **5/8** (보고서 [첫 번째](../../Last3Mon/71/answers/prep-20261018/71-lab03-challenge-cases-20261018-075719.json), [두 번째](../../Last3Mon/71/answers/prep-20261018/71-lab03-challenge-cases-20261018-075742.json)) |
|
||||
| ② | 규정을 열어 보니 이 질문의 답이 없음 → **정답표가 틀린 것** | — |
|
||||
| ③ | 이 질문을 "모르는 프로그램이 자꾸 저절로 떠요"로 바꿈 | **6/8** → 지금 Lab 03 과제에서 쓰는 케이스 파일 |
|
||||
|
||||
- 보고서 두 개는 수업이 끝난 뒤 공개되는 `Last3Mon/71/answers/prep-20261018/`에 있습니다. 수업 중에는 강사 화면에서 엽니다.
|
||||
- 정답표는 기억이 아니라 **원문을 열어 확인**하고 씁니다 (문서 이름, 섹션, 답 문구를 복사).
|
||||
- 검색이 "틀렸다"고 나오면, 고치기 전에 정답표부터 다시 봅니다.
|
||||
|
||||
## 4. 청크 · 메타데이터
|
||||
|
||||
### 4.1 오늘의 문서: 규정 8개, 섹션 25개
|
||||
|
||||
| `name` (데이터 API) | 제목 | 섹션 |
|
||||
| --- | --- | --- |
|
||||
| `password-policy` | 비밀번호·계정 보안 규정 | 4 (만들기 · 변경 주기 · 잠금 · 다단계 인증) |
|
||||
| `device-issue-return` | 업무용 장비 지급·반납 규정 | 4 (지급과 교체 · 분실과 도난 · 반납 · 개인 장비) |
|
||||
| `email-and-documents` | 메일·문서 보안 규정 | 3 |
|
||||
| `meeting-room` | 회의실 이용 규정 | 3 |
|
||||
| `privacy` | 개인정보 처리 지침 | 3 (수집 · 이용과 보관 · 유출 대응) |
|
||||
| `remote-work-vpn` | 원격근무·VPN 이용 규정 | 3 |
|
||||
| `security-incident` | 보안 사고 대응 절차 | 2 (피싱 메일 · 악성코드 감염 의심) |
|
||||
| `software-usage` | 소프트웨어 사용 규정 | 3 (설치와 승인 · 금지 사항 · 생성형 AI) |
|
||||
|
||||
문서 하나가 수백 바이트(526~928바이트)로 짧고, 모두 `## ` 섹션으로 나뉘어 있습니다. 실제 사내 규정은 훨씬 길지만 **모양**(제목 → 섹션 → 항목)은 같습니다.
|
||||
|
||||
### 4.2 색인 단계와 n8n 노드
|
||||
|
||||
| 단계 | 오늘의 선택 | n8n 노드 |
|
||||
| --- | --- | --- |
|
||||
| 문서 가져오기 | 데이터 API `/docs`, `/docs/<name>` (규정 8개) | HTTP Request, Split Out |
|
||||
| 청크 나누기 | `## ` 섹션 하나 = 청크 하나, 글 앞에 문서 제목 | Code |
|
||||
| 임베딩 | OpenAI `text-embedding-3-large` | Embeddings OpenAI |
|
||||
| 저장 | 메모리 벡터 저장소 `my_policy_docs` (+ 문서 이름 · 제목 메타데이터) | Vector Store In-Memory (insert) + Default Data Loader |
|
||||
| 검색 | 질문과 가까운 청크 `top_k`개 + 점수 | Vector Store In-Memory (load) |
|
||||
|
||||
### 4.3 청크 하나의 실제 모양
|
||||
|
||||
`password-policy`의 두 번째 청크는 이렇게 저장됩니다 (글 + 메타데이터 + 벡터):
|
||||
|
||||
```text
|
||||
글: 비밀번호·계정 보안 규정
|
||||
## 2. 변경 주기
|
||||
- 비밀번호는 90일마다 바꾼다. 만료 7일 전부터 사내 포털에 변경 안내가 표시된다.
|
||||
- 최근에 쓴 비밀번호 5개는 다시 쓸 수 없다.
|
||||
메타데이터: source = password-policy, title = 비밀번호·계정 보안 규정, chunk = 2 (과제에서 section = 2. 변경 주기)
|
||||
벡터: 3,072차원
|
||||
```
|
||||
|
||||
- **글 앞에 문서 제목을 붙입니다.** 섹션만 떼어 내면 "## 2. 변경 주기"만으로는 무엇의 변경 주기인지 모릅니다. 제목이 붙어야 "비밀번호" 질문과 가까워집니다.
|
||||
- **청크는 뜻 단위로.** 섹션은 한 가지 주제를 다룹니다. 글자 수로 자르면 한 규칙이 두 청크로 잘리거나, 두 주제가 한 청크에 섞입니다 (3단계에서 측정: 400자는 청크 12개로 줄고 doc@1 22/24).
|
||||
- **메타데이터가 출처.** 청크와 함께 문서 이름 · 제목(과제에서는 섹션 제목)을 저장해야 답에 출처를 붙일 수 있습니다. 벡터에서 출처를 되살릴 수는 없습니다.
|
||||
|
||||
### 4.4 "글 안에 있다"와 "칸으로 있다"는 다르다 (Lab 01 과제 미리 보기)
|
||||
|
||||
**무엇을 원했나.** Lab 01 과제에서 팀장이 "문서 이름만 말고 **섹션 제목**까지 알려 주세요"라고 합니다. 검색 결과의 1등마다 `section` 칸에 "1. 비밀번호 만들기"처럼 섹션 제목이 있어야 합니다.
|
||||
|
||||
**예제 2까지 만든 검색은 무엇을 돌려주나.** "비밀번호는 몇 자 이상이어야 하나요?"를 물으면 1등 결과가 이렇습니다.
|
||||
|
||||
| 예제 2까지 만든 검색 (과제 전) | 과제를 마친 검색 |
|
||||
| --- | --- |
|
||||
| `"source": "password-policy"` | `"source": "password-policy"` |
|
||||
| `"title": "비밀번호·계정 보안 규정"` | `"title": "비밀번호·계정 보안 규정"` |
|
||||
| (`section` 칸 **없음**) | `"section": "1. 비밀번호 만들기"` |
|
||||
| `"text": "비밀번호·계정 보안 규정\n## 1. 비밀번호 만들기\n- 비밀번호는 12자 이상으로 …"` | (같음) |
|
||||
|
||||
왼쪽을 보면 섹션 제목 "1. 비밀번호 만들기"가 **`text` 안에는 글자로 들어 있습니다.** 사람이 읽으면 어느 섹션인지 압니다. 하지만 `section`이라는 **칸**은 없습니다.
|
||||
|
||||
**그래서 테스트가 실패합니다.** 과제 테스트(`cases/lab01-challenge.json`)는 `hits.0.section` 칸을 읽어 "비밀번호 만들기"가 있는지 봅니다. 칸이 없으니 실패입니다.
|
||||
|
||||
```text
|
||||
✘ 섹션 · 비밀번호 길이 · 0.4s · hits.0.section has none of ['비밀번호 만들기']
|
||||
```
|
||||
|
||||
과제 테스트 4개 중 섹션을 보는 2개가 이렇게 실패하고, 개수(`top_k`)를 보는 2개는 통과해 **2/4**입니다 (10/18, 10/22 두 번 다).
|
||||
|
||||
**배울 것.** 2단계에서 답에 출처를 붙이는 Code, 3단계에서 채점하는 테스트는 모두 프로그램입니다. 프로그램은 글을 읽고 짐작하지 않고 **정해진 칸**만 읽습니다. 출처로 쓸 것은 처음부터 칸으로 만들어야 합니다.
|
||||
|
||||
**어떻게 고치나.** 섹션 제목은 **색인할 때** 청크를 자르면서 알 수 있으므로 그때 메타데이터(`section`)로 함께 저장합니다. 검색은 저장된 메타데이터를 꺼내 `section` 칸에 넣기만 하면 됩니다. 색인 · 검색 두 워크플로우를 모두 고치고, 다시 색인한 뒤 테스트하면 4/4입니다.
|
||||
|
||||
### 4.5 청크 크기는 어떻게 정하나 (3단계 예고)
|
||||
|
||||
| 너무 작으면 | 너무 크면 |
|
||||
| --- | --- |
|
||||
| 규칙 하나가 둘로 잘려 답 문구가 다음 청크로 넘어감 | 여러 주제가 섞여 점수가 흐려짐, LLM에 주는 글이 길어짐 |
|
||||
| "변경 주기"만 있고 무엇의 주기인지 없음 | 1등 청크에 답이 있어도 어디인지 찾기 어려움 |
|
||||
|
||||
정답은 "몇 자"가 아니라 **내 문서의 모양**입니다. 섹션이 있는 문서는 섹션부터 시작하고, 3단계에서 숫자로 확인합니다.
|
||||
|
||||
## 5. 메모리 저장소
|
||||
|
||||
오늘은 n8n 안의 **메모리** 벡터 저장소를 씁니다. 설치가 필요 없지만 주의할 점이 있습니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P["flow.py push"] --> R["n8n 재시작"] --> E[("저장소 빔")]
|
||||
E -->|"call my-search"| X["hits: [] · indexed: false"]
|
||||
E -->|"call my-index<br/>또는 test (케이스 파일의 before 칸)"| I[("청크 25개")]
|
||||
I --> S["검색 · 답"]
|
||||
```
|
||||
|
||||
| 성질 | 결과 | 대처 |
|
||||
| --- | --- | --- |
|
||||
| n8n이 재시작되면 지워짐 | `flow.py push`는 n8n을 재시작 → 저장소가 빔 | push 뒤에는 `call my-index`로 다시 색인. `test`는 아래 `before` 칸 덕분에 알아서 색인 |
|
||||
| 비어 있어도 검색은 실행됨 | 결과 없음 → 다음 노드가 멈출 수 있음 | `alwaysOutputData`, 다음 Code에서 문서가 있는 항목만 |
|
||||
| 같은 이름이면 워크플로우끼리 공유 | 색인과 검색이 같은 저장소를 씀 | 이름(`my_policy_docs`)을 계약에 적음 |
|
||||
| 색인할 때마다 비우고 다시 (`clearStore`) | 같은 청크가 두 번 들어가지 않음 | 두 번 색인하면 두 배가 되는 실수를 막음 |
|
||||
|
||||
**`before`는 명령이 아니라 케이스 파일(`cases/*.json`) 안의 칸입니다.** `flow.py test`가 케이스를 돌리기 전에 여기 적힌 호출을 한 번 합니다.
|
||||
|
||||
```json
|
||||
{
|
||||
"webhook": "my-search",
|
||||
"before": [{"webhook": "my-index", "request": "requests/index-section.json"}],
|
||||
"cases": [ ... ]
|
||||
}
|
||||
```
|
||||
|
||||
그래서 push로 저장소가 비어 있어도 `test`는 먼저 색인하고 시작하며, 출력 첫 줄에 `✔ before: POST /webhook/my-index · HTTP 200 · … {"indexed_chunks": 25, …}`가 찍힙니다. `--no-before`를 붙이면 이 호출을 건너뜁니다 (3단계에서 내가 다른 설정으로 색인해 둔 것을 그대로 잴 때).
|
||||
|
||||
잰 시간: push 직후 첫 색인 3.8초(2026-10-22), 그 뒤 `before` 칸으로 한 다시 색인 0.4~2.2초, 검색 한 번 0.2~0.9초 (수업 준비 때 색인 1.2초, 검색 0.2~0.4초).
|
||||
|
||||
### 5.1 운영에서는
|
||||
|
||||
| | 메모리 (오늘) | 운영용 벡터 DB (Qdrant, PGVector 등) |
|
||||
| --- | --- | --- |
|
||||
| 설치 | 없음 | 서버 · 컨테이너 |
|
||||
| 재시작 | 지워짐 | 남음 |
|
||||
| 다시 색인 | 매번 전부 | 바뀐 문서만 |
|
||||
| 여러 워크플로우 · 여러 서버 | 같은 n8n 안에서만 | 어디서나 |
|
||||
|
||||
오늘 배운 흐름(청크 → 임베딩 → 저장 → 검색)은 그대로이고, 저장소 노드만 바뀝니다. 7교시 `tdoc`은 SQLite 파일에 저장해 "껐다 켜도 남게" 직접 만듭니다.
|
||||
|
||||
## 6. 요청문으로
|
||||
|
||||
Lab과 다른 문서(사내 교육 안내 문서)로 예를 듭니다.
|
||||
|
||||
```text
|
||||
두 워크플로우를 만들어 줘. 노드는 AGENTS.md 5절.
|
||||
1. my-work/course-index.json (웹훅 my-course-index): GET http://data-api:8800/courses 목록 → 과정마다 본문
|
||||
→ Code: "### " 일정 블록마다 청크, 글 앞에 과정 이름, 메타데이터 course(코드)·name·block(일정 제목)
|
||||
→ 메모리 저장소 my_courses (insert, 매번 비우고) + text-embedding-3-large. 결과 {indexed_chunks}.
|
||||
2. my-work/course-search.json (웹훅 my-course-search): question 필수, top_k 기본 3,
|
||||
결과 {hits: [{rank, course, name, block, score, text}], top_score}. 저장소가 비어도 멈추지 않게.
|
||||
기대 결과: cases/course-search.json (이 파일의 before 칸으로 먼저 색인).
|
||||
```
|
||||
|
||||
- 청크 단위, 메타데이터, 저장소 이름, **비었을 때**를 적었습니다.
|
||||
|
||||
같은 일을 이렇게 시키면:
|
||||
|
||||
| 요청문 | 생기는 일 |
|
||||
| --- | --- |
|
||||
| "교육 문서로 RAG 만들어 줘" | 청크 크기 · 저장소 이름 · 결과 모양을 에이전트가 정함 → 테스트와 맞지 않음 |
|
||||
| "문서를 500자씩 잘라 줘" | 일정 블록이 잘림, 출처(블록 이름)가 없음 |
|
||||
| "검색 결과를 보여 줘" | `hits`의 칸 이름이 매번 달라짐, 저장소가 비면 워크플로우가 멈춤 |
|
||||
|
||||
요청문에 꼭 들어갈 것: **① 청크를 나누는 기준 ② 함께 저장할 메타데이터 ③ 저장소 이름(색인 · 검색이 같게) ④ 결과 칸 이름 ⑤ 비었을 때 ⑥ 기대 결과(테스트 파일)**.
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 검색 결과 1등 점수가 0.478이면 "47.8% 맞다"는 뜻인가요?</summary>
|
||||
|
||||
아닙니다. 같은 질문에 대한 청크들의 **순서**를 정하는 값입니다. 질문마다 점수대가 다르고(0.478~0.748), 모델을 바꾸면 점수대도 바뀝니다. 그래서 정답표로 "맞았나"를 따로 셉니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. "암호를 얼마나 자주 바꿔야 해?"는 규정에 "암호"라는 낱말이 없는데 어떻게 찾았나요?</summary>
|
||||
|
||||
임베딩은 낱말이 아니라 뜻으로 가까움을 잽니다. "암호"와 "비밀번호", "자주 바꾸다"와 "변경 주기"가 가까운 숫자 목록이 되어 1등(0.576)이 "2. 변경 주기"였습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. 청크 글 앞에 문서 제목을 붙이는 까닭은?</summary>
|
||||
|
||||
섹션만 떼면 "## 2. 변경 주기"처럼 무엇의 이야기인지 빠집니다. 제목이 있어야 질문의 주제("비밀번호")와 가까워지고, 사람이 읽어도 출처를 압니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. push한 뒤 바로 <code>call my-search</code>를 하면 무엇이 나오나요?</summary>
|
||||
|
||||
push가 n8n을 재시작해 메모리 저장소가 비었으므로 `hits`가 비고 `indexed: false`입니다. `call my-index`를 먼저 하거나, 케이스 파일에 `before` 칸이 있는 `test`를 씁니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 정답표에 답이 없는 질문을 넣는 까닭은?</summary>
|
||||
|
||||
뜻 검색은 언제나 가장 가까운 무언가를 돌려줍니다. 답이 없는 질문을 넣어 두어야 "찾았지만 관련 없음"을 걸러 내는지(2단계)를 시험할 수 있습니다.
|
||||
|
||||
오늘 넣은 곳:
|
||||
|
||||
| 어디 | 답이 없는 질문 | 시험하는 것 |
|
||||
| --- | --- | --- |
|
||||
| Lab 01 예제 1 정답표 (종이, 에이전트 없이) | 연차 휴가 | 정답표에 "없음"을 쓰는 습관 |
|
||||
| `cases/lab02.json` | 점심 메뉴 | 관련도 기준 → 담당자 연결 |
|
||||
| `cases/lab02-challenge.json` | VPN 속도, 노트북 사양, 비밀번호 잊음, 보안 교육, 연차 | 점수는 높은데 답이 없음 → 답 검사 |
|
||||
| `cases/lab03-threshold.json` | 점심, 연차, 영화, 맛집, 연봉 | 기준값 0.33이 두 무리를 나누는지 |
|
||||
|
||||
검색 테스트(`cases/lab01.json`, `retrieval-*.json` 24문항)에는 없습니다. 검색 테스트는 "답이 있는 질문에서 맞는 것을 1등으로 찾나"만 봅니다.
|
||||
</details>
|
||||
|
||||
## 정리
|
||||
|
||||
- [ ] RAG = 색인(가끔) + 질문할 때마다 검색 → 그 내용으로만 답. 지시문 · 파인튜닝 · Tool과 무엇이 다른지 말할 수 있다
|
||||
- [ ] 점수는 순서의 근거이지 확률이 아니다. 1등과 2등의 차이, "관련 없는 점수대"를 본다
|
||||
- [ ] 정답표가 먼저 (답이 없는 질문 포함), 정답표도 원문으로 확인한다
|
||||
- [ ] 청크는 뜻 단위, 글 앞에 제목, 메타데이터가 출처. 글 안에 있는 것과 칸으로 있는 것은 다르다
|
||||
- [ ] 메모리 저장소는 재시작에 지워진다 → 테스트 전에 색인
|
||||
@@ -0,0 +1,330 @@
|
||||
# 2단계 · 근거로 답하는 RAG 워크플로우
|
||||
|
||||
- 교시: 3~4교시 (11:00~12:50) · 3교시 강의 약 30분 + Lab 02 예제, 4교시 과제 · 풀이
|
||||
- 실습: [Lab 02](../../Last3Mon/71/LAB-02-Q-ANSWER-FROM-POLICIES.md)
|
||||
- 이 단계가 끝나면: 검색한 발췌로만 답하고 출처를 붙이는 워크플로우를 만들고, 관련 없는 질문과 **답이 없는 질문**을 서로 다른 장치로 넘길 수 있다.
|
||||
- 이 교안의 숫자: 2026-10-18 수업 준비 측정, 2026-10-22 같은 정답으로 다시 돌린 기록 (`gpt-4.1-mini`, `text-embedding-3-large`)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 발췌로만 답하기"] --> B["2. 번호로 출처"] --> C["3. 관련도 기준"] --> D["4. 점수는 높은데<br/>답이 없을 때"] --> E["5. 답 검사"] --> F["6. 넘기는 길 설계"]
|
||||
```
|
||||
|
||||
| 절 | 말하는 시간 (예) | 띄울 것 |
|
||||
| --- | --- | --- |
|
||||
| 1. 발췌로만 답하기 | 6분 | 발췌의 실제 모양, 실측 답 |
|
||||
| 2. 번호로 출처 | 4분 | `sources` · `cited` 실례 |
|
||||
| 3. 관련도 기준 | 6분 | 10개 점수표, 기준 정하는 순서 |
|
||||
| 4. 점수는 높은데 답이 없을 때 | 6분 | 기준값만 쓴 결과 |
|
||||
| 5. 답 검사 | 6분 | 검사 4가지, 검사 결과 JSON |
|
||||
| 6. 넘기는 길 설계 · 확인 질문 | 2분 + 과제 뒤 | route 세 갈래 |
|
||||
|
||||
## 1. 발췌로만 답하기
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Q(["질문"]) --> S["검색 top 3"] --> C["Build context<br/>[1] [2] [3] 발췌"] --> L{{"Answer from policies"}} --> B["Build answer<br/>번호 → 제목"] --> R(["답 + 출처"])
|
||||
```
|
||||
|
||||
### 1.1 LLM이 실제로 받는 글
|
||||
|
||||
"암호를 얼마나 자주 바꿔야 해?"를 물으면 검색 1~3등(2. 변경 주기 0.576, 1. 만들기 0.512, 4. 다단계 인증 0.456)이 번호를 달고 LLM에게 갑니다.
|
||||
|
||||
```text
|
||||
질문: 암호를 얼마나 자주 바꿔야 해?
|
||||
|
||||
규정 발췌:
|
||||
[1] 비밀번호·계정 보안 규정
|
||||
## 2. 변경 주기
|
||||
- 비밀번호는 90일마다 바꾼다. 만료 7일 전부터 사내 포털에 변경 안내가 표시된다.
|
||||
- 최근에 쓴 비밀번호 5개는 다시 쓸 수 없다.
|
||||
|
||||
[2] 비밀번호·계정 보안 규정
|
||||
## 1. 비밀번호 만들기
|
||||
- 비밀번호는 12자 이상으로 만든다. …
|
||||
|
||||
[3] 비밀번호·계정 보안 규정
|
||||
## 4. 다단계 인증
|
||||
- 회사 밖에서 사내 시스템에 접속할 때는 OTP 다단계 인증을 반드시 사용한다. …
|
||||
```
|
||||
|
||||
LLM은 **이 글만** 봅니다. 규정 전체도, 다른 문서도 보지 않습니다. 그래서 1단계의 검색이 틀리면 여기서 고칠 방법이 없습니다.
|
||||
|
||||
### 1.2 지시문의 세 가지
|
||||
|
||||
| 지시 | 이유 |
|
||||
| --- | --- |
|
||||
| 발췌에 있는 내용으로만 | 지어내지 않게 (LLM이 아는 일반론을 섞지 않게) |
|
||||
| 사실마다 `[번호]` | 코드가 출처를 확인할 수 있게 |
|
||||
| 없으면 정확히 "규정에서 답을 찾지 못했습니다." | 모를 때의 답을 정해 둠 (그래도 다르게 말하기도 함, 4절) |
|
||||
|
||||
한국어 3문장 이내도 정합니다. 길면 발췌에 없는 설명이 붙기 쉽습니다.
|
||||
|
||||
### 1.3 실제 답 (`cases/lab02.json` 6/6, 2026-10-22)
|
||||
|
||||
| 질문 | 답 (앞부분) | 시간 |
|
||||
| --- | --- | --- |
|
||||
| 암호를 얼마나 자주 바꿔야 해? | "암호는 90일마다 변경해야 하며, 만료 7일 전부터 사내 포털에 변경 안내가 표시됩니다. … [비밀번호·계정 보안 규정]" | 3.0초 |
|
||||
| 회사를 그만두면 노트북은 언제까지 돌려줘야 하나요? | "…퇴사 후 5영업일 이내에 IT 담당자에게 반납해야 합니다. … [업무용 장비 지급·반납 규정]" | 1.8초 |
|
||||
| 첨부 파일이 너무 커서 메일이 안 보내져요 | "메일 첨부 파일은 25MB까지 … 사내 드라이브에 올리고 공유 링크를 … [메일·문서 보안 규정]" | 2.1초 |
|
||||
| 오늘 점심 메뉴 추천해줘 | "규정에서 답을 찾지 못했습니다. IT 문의 창구로 연결해 드릴게요." (LLM 없음) | 0.3초 |
|
||||
|
||||
- 질문은 "암호"라고 물었는데 답도 "암호는 …"으로 시작합니다. LLM은 질문의 말투를 따르고, **내용**은 발췌를 따릅니다.
|
||||
- LLM을 부르는 답은 1.8~3.0초, 부르지 않는 답은 0.3초입니다 (수업 준비 때 답 1.7~2.2초). 72일차에 이 차이를 재고 줄입니다.
|
||||
|
||||
### 1.4 틀린 전제
|
||||
|
||||
"비밀번호는 30일마다 바꾸면 되죠?"에는 "비밀번호는 30일마다 바꾸는 것이 아니라 90일마다 바꿔야 합니다. …"라고 답했습니다 (`top_score` 0.685). 질문이 아니라 **발췌**가 답의 기준이 됩니다. 사용자가 "맞죠?"라고 물으면 맞장구치기 쉬운 LLM을 발췌가 붙잡아 줍니다.
|
||||
|
||||
## 2. 번호로 출처
|
||||
|
||||
- LLM은 `[2]`처럼 **번호**만 씁니다. 번호를 문서 제목으로 바꾸고 `cited`(인용한 문서)를 만드는 것은 **Code**입니다.
|
||||
- 범위 밖 번호(`[7]`)는 버립니다. LLM이 쓴 제목을 그대로 믿지 않습니다 (67일차 `sources`와 같은 생각).
|
||||
- 결과에 `sources`(검색된 문서)와 `cited`(답이 인용한 문서)를 따로 둡니다.
|
||||
|
||||
### 2.1 질문 하나를 따라가 보기
|
||||
|
||||
질문: **"생성형 AI에 고객 자료를 넣어도 되나요?"** (실측)
|
||||
|
||||
**① 검색이 3개를 찾고 번호를 붙입니다.**
|
||||
|
||||
| 번호 | 문서 (`source`) | 섹션 | 점수 |
|
||||
| --- | --- | --- | --- |
|
||||
| [1] | `software-usage` (소프트웨어 사용 규정) | 3. 생성형 AI 서비스 | 0.51 |
|
||||
| [2] | `privacy` (개인정보 처리 지침) | 2. 이용과 보관 | 0.367 |
|
||||
| [3] | `privacy` (개인정보 처리 지침) | 1. 수집 | 0.336 |
|
||||
|
||||
**② LLM은 발췌 [1] [2] [3]을 읽고, 쓴 사실 뒤에 번호를 붙입니다.**
|
||||
|
||||
```text
|
||||
"… 고객 정보, 개인정보, 대외비 문서는 생성형 AI 서비스에 입력하지 않는 것이 규정입니다[1]."
|
||||
```
|
||||
|
||||
**③ Code가 결과의 두 칸을 만듭니다.**
|
||||
|
||||
| 칸 | 만드는 법 | 이 질문의 값 |
|
||||
| --- | --- | --- |
|
||||
| `sources` | 검색된 3개의 문서를 **중복 없이** 모음 ([1] · [2] · [3]) | `software-usage`, `privacy` (`privacy`가 두 번 나와 하나로) |
|
||||
| `cited` | 답 안에 나온 **번호만** 문서로 바꿔 모음 | 답에 `[1]`만 있음 → `software-usage` |
|
||||
| 답의 `[1]` | 번호를 그 문서의 제목으로 바꿈 | `[소프트웨어 사용 규정]` |
|
||||
|
||||
→ `sources`는 "LLM에게 **보여 준** 문서", `cited`는 "LLM이 답에 **실제로 쓴** 문서"입니다. 개인정보 지침도 보여 줬지만 답에는 쓰지 않았습니다.
|
||||
|
||||
### 2.2 두 칸을 비교해 읽기 (실측)
|
||||
|
||||
| 질문 | 보여 준 문서 (`sources`) | 답에 쓴 문서 (`cited`) | 읽는 법 |
|
||||
| --- | --- | --- | --- |
|
||||
| 생성형 AI에 고객 자료를 넣어도 되나요? | 소프트웨어, 개인정보 | 소프트웨어 | 위 2.1. 정상 |
|
||||
| 첨부 파일이 너무 커서 메일이 안 보내져요 | 메일·문서, 보안 사고 | 메일·문서 | 3등(보안 사고 · 피싱 메일 0.335)은 관련 없어 쓰지 않음. 정상 |
|
||||
| 비밀번호를 잊어버리면 어디서 바꿔요? | 비밀번호 | **없음** | 보여 줬는데 하나도 쓰지 않음. 답이 "규정에서 답을 찾지 못했습니다." → 발췌에 답이 없었다는 **신호** (4절) |
|
||||
|
||||
`cited`가 비어 있으면 답이 발췌를 근거로 하지 않았다는 뜻입니다. 5절 답 검사의 `cites_excerpt`가 이것을 봅니다.
|
||||
|
||||
왜 제목을 LLM에게 쓰게 하지 않나요? LLM은 발췌에 없는 제목("IT 보안 정책")을 만들어 내거나 비슷한 제목을 섞을 수 있습니다. 번호는 **코드가 범위를 확인**할 수 있고, 제목은 저장해 둔 메타데이터에서 가져오므로 틀릴 수 없습니다.
|
||||
|
||||
## 3. 관련도 기준
|
||||
|
||||
검색은 **언제나** 가장 가까운 청크 k개를 돌려줍니다. 점심 메뉴를 물어도 무언가 나옵니다. 1등 점수(`top_score`)가 기준보다 낮으면 LLM을 부르지 않고 넘깁니다.
|
||||
|
||||
### 3.1 실제로 잰 10개 (`cases/lab03-threshold.json` 10/10, 2026-10-22)
|
||||
|
||||
| 규정 질문 | `top_score` | | 규정 밖 질문 | `top_score` |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 첨부 파일이 너무 커서 … | 0.616 | | 올해 연봉 인상률은요? | 0.261 |
|
||||
| 암호를 얼마나 자주 … | 0.575 | | 연차 휴가는 며칠이에요? | 0.259 |
|
||||
| 생성형 AI에 고객 자료를 … | 0.51 | | 회사 근처 맛집 알려 줘 | 0.232 |
|
||||
| 컴퓨터가 바이러스에 … | 0.478 | | 주말에 볼 영화 추천해 주세요 | 0.211 |
|
||||
| 회사를 그만두면 노트북은 … | 0.464 | | 오늘 점심 메뉴 추천해줘 | 0.202 |
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph out["규정 밖 0.202 ~ 0.261"]
|
||||
o1["점심 · 영화 · 맛집 · 연차 · 연봉"]
|
||||
end
|
||||
T{{"기준 0.33"}}
|
||||
subgraph in["규정 질문 0.464 ~ 0.616"]
|
||||
i1["첨부 · 암호 · 생성형 AI · 바이러스 · 노트북"]
|
||||
end
|
||||
out --- T --- in
|
||||
```
|
||||
|
||||
- 기준 0.33: 둘 다 맞게 나눔 (10/10). 넘기는 경우는 0.3~0.5초 (LLM 없음).
|
||||
- 두 무리 사이가 0.2쯤 벌어져 있어 0.33은 여유가 있습니다.
|
||||
|
||||
### 3.2 기준값을 정하는 순서
|
||||
|
||||
1. 답이 **있는** 질문 몇 개, 답이 **없는**(관련 없는) 질문 몇 개를 정답표에서 고릅니다.
|
||||
2. 두 무리의 `top_score`를 잽니다 (위 표).
|
||||
3. 두 무리 **사이**에서, 경계에 딱 붙지 않게 고릅니다 (1단계 2.4절: 점수는 셋째 자리에서 흔들림).
|
||||
4. 테스트 파일(`lab03-threshold.json`)로 남겨, 모델이나 청크를 바꿀 때마다 다시 돌립니다.
|
||||
|
||||
기준값은 **임베딩 모델마다 다릅니다.** 같은 질문도 모델이 바뀌면 점수대가 통째로 움직이므로, 다른 모델에서 가져온 숫자를 그대로 쓰지 않습니다.
|
||||
|
||||
### 3.3 기준은 양쪽으로 틀린다
|
||||
|
||||
| 기준을 올리면 | 기준을 낮추면 |
|
||||
| --- | --- |
|
||||
| 진짜 규정 질문도 넘김 (사람 일이 늘어남) | 관련 없는 질문에 LLM이 답을 씀 (지어낼 위험) |
|
||||
| 예: 0.47로 올리면 "퇴사 노트북"(0.464)이 넘어감 | 예: 0.2로 내리면 점심 메뉴(0.202)에도 답을 씀 |
|
||||
|
||||
실제로 기준 근처에 있는 질문도 있습니다. 3단계 24문항 가운데:
|
||||
|
||||
| 질문 | 1등 | `top_score` | 규정에 답이 |
|
||||
| --- | --- | --- | --- |
|
||||
| 공짜 프로그램은 그냥 써도 되죠? | 소프트웨어 · 1. 설치와 승인 | **0.267** | **있음** ("라이선스") |
|
||||
| 자리 비울 때 화면은 몇 분 뒤 잠기게 해요? | 원격근무 · 3. 재택근무 중 보안 | 0.354 | 있음 ("5분") |
|
||||
|
||||
"공짜 프로그램"은 규정에 답이 있는데 점수가 0.33보다 낮습니다. 이 점수면 규정 Q&A는 LLM을 부르지 않고 **담당자 연결**로 보냅니다. 기준값은 "답이 있는 질문을 넘기는" 쪽으로도 틀립니다. 그래도 지어낸 답을 내보내는 것보다 사람에게 넘기는 쪽이 안전하다고 보고 0.33을 둡니다. 이런 질문은 3단계의 질문 다시 쓰기로 점수를 올리는 길도 있습니다.
|
||||
|
||||
## 4. 점수는 높은데 답이 없을 때
|
||||
|
||||
### 4.1 기준값만 쓴 결과 (예제 정답, 2026-10-22, `lab02-challenge` 2/8)
|
||||
|
||||
| 질문 | `top_score` | route | LLM의 답 | `cited` |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| VPN 접속 속도가 느리면 어떻게 해요? | 0.463 | 자동 답변 | "규정에서는 VPN 접속 속도가 느릴 때의 대처 방법에 대해 언급하고 있지 않습니다. 따라서 규정에서 답을 찾지 못했습니다." | 없음 |
|
||||
| 노트북 사양은 어떻게 되나요? | 0.379 | 자동 답변 | "규정 발췌에는 노트북 사양에 대한 내용이 포함되어 있지 않습니다. … [업무용 장비 지급·반납 규정][메일·문서 보안 규정][업무용 장비 지급·반납 규정]" | **2개** |
|
||||
| 비밀번호를 잊어버리면 어디서 바꿔요? | 0.551 | 자동 답변 | "규정에서 답을 찾지 못했습니다." | 없음 |
|
||||
| 보안 교육은 1년에 몇 번 받아야 하나요? | 0.352 | 자동 답변 | "규정에서 답을 찾지 못했습니다." | 없음 |
|
||||
| 연차 휴가는 며칠이에요? | 0.259 | 담당자 연결 | (LLM 없음) | 없음 |
|
||||
|
||||
**왜 답이 없나.** 이 질문들은 Lab 02 과제용으로 일부러 고른 것입니다. 낱말은 규정과 겹쳐 점수가 기준을 넘지만, 묻는 **내용**은 규정 8개 어디에도 없습니다 (원문 확인).
|
||||
|
||||
| 질문 | 점수를 올린 규정 | 그 규정에 있는 것 | 없는 것 (질문이 묻는 것) |
|
||||
| --- | --- | --- | --- |
|
||||
| VPN 접속 속도가 느리면? | 원격근무·VPN | VPN 먼저 연결, 공용 와이파이 금지, 인증서 1년 · 30일 전 재발급, 화면 잠금 | 속도가 느릴 때 할 일 |
|
||||
| 노트북 사양은? | 장비 지급·반납 | 입사일 지급, 교체 주기 4년, 분실 신고, 반납 | 사양 (CPU · 메모리 등) |
|
||||
| 비밀번호를 잊어버리면 어디서 바꿔요? | 비밀번호·계정 보안 | 12자 이상, 90일마다 변경, 5번 실패 시 30분 잠금, OTP 재등록 | 잊었을 때 다시 만드는 곳 · 방법 |
|
||||
| 보안 교육은 1년에 몇 번? | 보안 사고 대응 | 피싱 메일 신고, 악성코드 감염 시 네트워크 분리 | 보안 교육 이야기 전부 |
|
||||
| 연차 휴가는 며칠? | (가까운 규정 없음) | 규정 8개가 모두 IT 규정 | 인사 · 휴가 규정 자체 |
|
||||
|
||||
LLM은 발췌를 읽고 "찾지 못했다"고 **옳게** 답했습니다. 잘못은 워크플로우가 그 답을 `자동 답변`으로 내보낸 데 있습니다.
|
||||
|
||||
- 규정에 **비슷한 낱말**(VPN, 노트북, 비밀번호, 보안)이 있어 점수가 기준을 넘습니다. 기준을 0.47로 올리면 "퇴사 노트북"(0.464) 같은 진짜 규정 질문도 걸립니다 → **기준값으로는 못 거릅니다.**
|
||||
- LLM은 모두 "못 찾았다"고 **말했지만**, 워크플로우는 그 답을 `자동 답변`으로 내보냈습니다. 직원 화면에는 "자동 답변: 규정에서 답을 찾지 못했습니다"가 뜨고, 아무도 이 문의를 이어받지 않습니다.
|
||||
- 정해 준 문장 대신 "언급하고 있지 않습니다", "포함되어 있지 않습니다"처럼 **다르게** 말합니다.
|
||||
- "노트북 사양"은 "내용이 없다"고 하면서 **출처를 셋이나** 붙였습니다. 출처가 있다고 근거 있는 답은 아닙니다 → 검사 하나로는 부족합니다.
|
||||
|
||||
### 4.2 왜 이런 일이 생기나
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Q["노트북 사양은?"] --> S["검색: 장비 규정 0.379<br/>(노트북이라는 말이 있음)"] --> T{"≥ 0.33"} -->|예| L["LLM: 발췌에 사양은 없다"] --> R["route = 자동 답변"]
|
||||
```
|
||||
|
||||
검색은 **주제**가 같은지를 보고, 답은 **내용**이 있는지가 중요합니다. 장비 규정은 노트북 이야기(지급 · 분실 · 반납)이지만 사양은 없습니다. 주제가 같으면 점수가 높고, 내용이 없으면 답이 없습니다. 이 틈은 검색 점수로는 볼 수 없고, **답을 보고** 판단해야 합니다.
|
||||
|
||||
## 5. 답 검사
|
||||
|
||||
67일차 Check answer처럼, LLM의 답을 코드로 검사하고 하나라도 실패하면 담당자에게 넘깁니다.
|
||||
|
||||
### 5.1 검사 넷
|
||||
|
||||
| 검사 | 확인 | 잡는 것 | 계산 방법 |
|
||||
| --- | --- | --- | --- |
|
||||
| `found_in_policies` | "찾지 못했", "포함되어 있지 않", "명시되어 있지 않", "언급이 없", "나와 있지 않"이 없나 | 답이 없는 질문 | 답 글에서 문구 찾기 (정규식) |
|
||||
| `cites_excerpt` | 인용 번호가 하나 이상인가 | 출처 없는 답 | 범위 안의 `[번호]` 개수 |
|
||||
| `grounded` | 답 글의 두 글자 묶음 30% 이상이 발췌에 있나 | 발췌와 상관없는 답 | 아래 5.2 |
|
||||
| `numbers_from_policies` | 답의 숫자가 모두 발췌에 있나 | 지어낸 숫자 | 답의 숫자마다 발췌에서 찾기 |
|
||||
|
||||
### 5.2 `grounded`는 어떻게 세나
|
||||
|
||||
답에서 `[번호]`와 띄어쓰기를 빼고, 두 글자씩 묶습니다. "90일마다변경" → `90` `0일` `일마` `마다` `다변` `변경`. 이 묶음 중 발췌에도 있는 것이 30% 이상이면 통과입니다.
|
||||
|
||||
- 발췌의 말을 거의 그대로 옮긴 답은 높게 나오고, LLM이 아는 일반론("보통 IT 부서에 문의하시면…")을 쓴 답은 낮게 나옵니다.
|
||||
- LLM으로 "근거가 있나"를 묻는 방법도 있지만, 그것도 LLM입니다. 두 글자 묶음은 **빠르고, 늘 같은 결과**이고, 왜 실패했는지 보여 줄 수 있습니다. 대신 말을 바꿔 쓴 좋은 답을 떨어뜨릴 수 있어 30%처럼 느슨하게 둡니다.
|
||||
|
||||
### 5.3 검사 결과 (과제 정답, `lab02-challenge` 2/8 → 8/8 · `--repeat 3` 24/24, `lab02` 6/6)
|
||||
|
||||
```json
|
||||
{
|
||||
"route": "담당자 연결",
|
||||
"answer": "규정에서 확실한 답을 찾지 못해 IT 담당자에게 전달했습니다.",
|
||||
"draft": "규정에서는 VPN 접속 속도가 느릴 때의 대처 방법에 대해 언급하고 있지 않습니다. 따라서 답변을 드리기 어렵습니다. 규정에서 답을 찾지 못했습니다.",
|
||||
"cited": [],
|
||||
"top_score": 0.462,
|
||||
"checks": [
|
||||
{"name": "found_in_policies", "passed": false},
|
||||
{"name": "cites_excerpt", "passed": false},
|
||||
{"name": "grounded", "passed": false},
|
||||
{"name": "numbers_from_policies", "passed": true}
|
||||
],
|
||||
"failed": ["found_in_policies", "cites_excerpt", "grounded"]
|
||||
}
|
||||
```
|
||||
|
||||
- 답이 없는 네 질문은 모두 `found_in_policies` · `cites_excerpt` · `grounded` 셋이 실패했습니다. 하나만 있었어도 걸렸겠지만, **여러 검사가 겹쳐** 있어 LLM이 말을 바꾸거나 출처를 붙여도 놓치지 않습니다.
|
||||
- 근거 있는 답("암호", "바이러스", 틀린 전제)은 넷 다 통과해 그대로 `자동 답변`입니다.
|
||||
- `draft`에 LLM의 원래 답을 남깁니다. 담당자가 이어받을 때 "무엇을 찾았고 왜 넘어왔는지"를 봅니다.
|
||||
- 검사는 코드라 시간이 거의 들지 않습니다. 과제 정답에서 LLM을 부른 답은 1.1~1.9초였습니다 (`--repeat 3`, 2026-10-22).
|
||||
|
||||
> 장치마다 잡는 실패가 다릅니다. **관련도 기준** = 엉뚱한 질문 (빠르고 쌈, LLM을 부르지 않음), **답 검사** = 비슷하지만 답이 없는 질문, 지어낸 숫자 (LLM을 부른 뒤).
|
||||
|
||||
## 6. 넘기는 길 설계
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Q(["질문"]) --> S["검색"] --> T{"top_score ≥ 기준?"}
|
||||
T -->|아니오| H1(["담당자 연결<br/>'규정에서 답을 찾지 못했습니다. IT 문의 창구로…'"])
|
||||
T -->|예| L{{"발췌로만 답"}} --> K{"답 검사 통과?"}
|
||||
K -->|예| A(["자동 답변 + 출처"])
|
||||
K -->|아니오| H2(["담당자 연결<br/>'확실한 답을 찾지 못해 IT 담당자에게 전달…' + draft"])
|
||||
```
|
||||
|
||||
| 갈래 | 언제 | 직원이 보는 말 | 담당자가 받는 것 |
|
||||
| --- | --- | --- | --- |
|
||||
| 자동 답변 | 기준 통과 + 검사 통과 | 답 + `[문서 제목]` | (없음) |
|
||||
| 담당자 연결 (기준) | 관련 있는 규정이 없음 | "규정에서 답을 찾지 못했습니다. IT 문의 창구로 연결해 드릴게요." | 질문, `top_score` |
|
||||
| 담당자 연결 (검사) | 규정은 비슷한데 답이 없거나 근거가 약함 | "규정에서 확실한 답을 찾지 못해 IT 담당자에게 전달했습니다." | 질문, `draft`, `failed` |
|
||||
|
||||
- 두 담당자 연결의 **말이 다릅니다.** 담당자는 "규정에 아예 없는 질문"과 "규정이 모자란 질문"을 다르게 처리합니다. 뒤쪽이 쌓이면 **규정을 보완할 곳**입니다 (VPN 속도, 노트북 사양, 비밀번호 찾기, 보안 교육 횟수).
|
||||
- 69일차 검토자의 fail-closed와 같은 생각입니다: **확실하지 않으면 자동으로 내보내지 않습니다.**
|
||||
|
||||
### 6.1 앞 일차와의 연결
|
||||
|
||||
오늘 2단계는 새로 배우는 것이 아니라 **앞에서 한 세 가지를 RAG에 다시 쓰는 것**입니다.
|
||||
|
||||
| 일차 | 그때 만든 것 (장면 하나) | 그때 배운 것 | 오늘 같은 자리 |
|
||||
| --- | --- | --- | --- |
|
||||
| 64 Lab 02 | `miniflow`로 날씨 Tool → LLM. `city=제주`면 Tool 결과(`비`, 비 올 확률 80%)가 LLM 지시문에 끼워져 "우산이 필요합니다" | **근거를 지시문에 넣어 주면** LLM은 그것으로 답한다 (Tool → LLM 근거 제공 패턴) | 검색한 발췌 `[1] [2] [3]`을 지시문에 넣음 (1.1절). 날씨 Tool 자리에 검색이 들어감 |
|
||||
| 67 Lab 01 과제 | IT 문의 Agent가 FAQ Tool로 답하고 `sources`에 `FAQ-001`처럼 출처를 남김 | 출처를 **LLM이 쓰게 할지, Tool 결과에서 코드가 찾게 할지** 정해야 함 | LLM은 번호만, 번호 → 문서 제목 · `cited`는 Code (2절) |
|
||||
| 67 Lab 03 | Agent 답 뒤에 "결과 검증" 노드: 검사 여러 개, 하나라도 실패하면 `route: 담당자 연결` + 원래 답 `draft` + 걸린 검사 `failed` | LLM 답을 **코드로 검사**하고, 실패하면 사람에게 넘긴다 | 답 검사 넷과 같은 결과 모양 (`checks`, `failed`, `draft`) (5절) |
|
||||
| 69 Lab 03 | 공지 팀(작성자 → 검토자 → 정리자)에서 **검토자를 꺼 봄**. 검토 결과(`passed`)가 없는데 `게시 가능`이 되면 가장 위험 | **fail-closed**: 확실하지 않으면 내보내지 않는다 (68일차는 fail-open: 하나가 꺼져도 나머지 답은 냄) | 검사 실패, 점수 미달 → `자동 답변` 하지 않고 담당자 연결 (6절) |
|
||||
| 72 (내일) Lab 01 | `flow.py bench`로 같은 요청을 여러 번 보내 단계별 시간을 재고 가장 느린 단계를 찾음 | 느린 곳은 **재서** 찾는다 | 오늘 잰 것: LLM 없는 길 0.3초 vs LLM을 부르는 길 1.8~3.0초 |
|
||||
|
||||
수업에서는 "64일차 우산 질문 기억나나요? 그 날씨 Tool 자리에 오늘은 규정 검색이 들어갑니다"처럼 장면부터 꺼내면 됩니다.
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 관련도 기준을 높이면 "답이 없는 질문" 문제가 풀리지 않나요?</summary>
|
||||
|
||||
아닙니다. 답이 없는 질문(0.352~0.551)과 진짜 규정 질문(0.464~0.616)의 점수대가 겹칩니다. 0.47로 올리면 "퇴사 노트북"(0.464)이 넘어가고, 그래도 "비밀번호 잊음"(0.551)은 남습니다. 답을 보고 판단하는 답 검사가 필요합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. "노트북 사양" 답에는 출처가 셋이나 있는데 왜 담당자에게 넘기나요?</summary>
|
||||
|
||||
답이 "내용이 포함되어 있지 않다"고 말하고 있습니다 (`found_in_policies` 실패). 출처가 있다는 것은 "발췌를 봤다"는 뜻이지 "발췌에 답이 있다"는 뜻이 아닙니다. 과제 정답에서는 출처가 붙지 않았지만, 붙더라도 다른 검사가 잡습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. <code>cited</code>를 LLM이 JSON으로 돌려주게 하면 안 되나요?</summary>
|
||||
|
||||
LLM은 없는 문서 이름을 만들거나 형식을 어길 수 있습니다. 번호를 쓰게 하고 코드가 범위를 확인한 뒤 저장된 메타데이터에서 이름을 가져오면, 출처가 틀릴 수 없습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. "공짜 프로그램은 그냥 써도 되죠?"(0.267)가 담당자에게 넘어가는 것은 실패인가요?</summary>
|
||||
|
||||
규정에 답이 있으니 놓친 것은 맞습니다. 하지만 지어낸 답이 나가는 것보다 덜 위험한 쪽으로 틀렸습니다. 이런 질문은 정답표에 남겨 두고, 3단계(질문 다시 쓰기)나 기준값 조정으로 나아지는지 숫자로 확인합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 담당자 연결을 왜 두 가지 말로 나누나요?</summary>
|
||||
|
||||
"규정에 없는 주제"(점심 메뉴)와 "규정은 있는데 답이 모자란 질문"(VPN 속도)은 처리가 다릅니다. 뒤쪽은 규정 담당자가 문서를 보완할 거리이고, `draft` · `failed`가 그 근거가 됩니다.
|
||||
</details>
|
||||
|
||||
## 정리
|
||||
|
||||
- [ ] 발췌로만, 번호로 출처, 모를 때의 답을 정한다. LLM은 발췌만 본다
|
||||
- [ ] 번호 → 제목, `cited`는 코드가 만든다. `sources`와 `cited`가 다르면 이유가 있다
|
||||
- [ ] 관련도 기준은 모델마다 두 무리를 재서 정하고, 양쪽으로 틀릴 수 있음을 안다
|
||||
- [ ] 기준값으로 못 거르는 "답 없는 질문"은 답 검사(여러 개를 겹쳐)로
|
||||
- [ ] 넘기는 길은 이유마다 다르게, 담당자가 이어받을 것(`draft`, `failed`)을 남긴다
|
||||
@@ -0,0 +1,398 @@
|
||||
# 3단계 · 검색 품질 측정과 개선
|
||||
|
||||
- 교시: 5~6교시 (14:00~15:50) · 5교시 강의 약 30분 + Lab 03 예제, 6교시 과제 · 풀이
|
||||
- 실습: [Lab 03](../../Last3Mon/71/LAB-03-Q-MEASURE-AND-IMPROVE.md)
|
||||
- 이 단계가 끝나면: 검색 품질을 doc@1 · answer@1 · answer@3로 재고, 설정을 한 번에 하나씩 바꿔 비교하며, 개선이 다른 것을 깨뜨리지 않았는지 확인할 수 있다.
|
||||
- 이 교안의 숫자: 2026-10-18 수업 준비 측정(1회), 2026-10-22 같은 정답으로 다시 돌린 기록. 두 날이 다른 곳은 따로 적었습니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 지표 셋"] --> B["2. 재는 순서"] --> C["3. 청크 크기"] --> D["4. 어려운 질문과<br/>질문 다시 쓰기"] --> E["5. 같은 설정,<br/>다른 결과"] --> F["6. 무엇을 고를까"]
|
||||
```
|
||||
|
||||
| 절 | 말하는 시간 (예) | 띄울 것 |
|
||||
| --- | --- | --- |
|
||||
| 1. 지표 셋 | 6분 | 지표 표, 1등이 아슬아슬한 예 |
|
||||
| 2. 재는 순서 | 4분 | 순서 그림, 실험 기록 |
|
||||
| 3. 청크 크기 | 7분 | 설정 표, 잘린 문장 · 섞인 청크 |
|
||||
| 4. 어려운 질문과 다시 쓰기 | 7분 | 8개 표 (다시 쓴 검색어) |
|
||||
| 5. 같은 설정, 다른 결과 | 3분 | 10/18 vs 10/22 |
|
||||
| 6. 무엇을 고를까 · 확인 질문 | 3분 + 과제 뒤 | 개선 방법 표 |
|
||||
|
||||
## 1. 지표 셋
|
||||
|
||||
**지표는 검색을 채점하는 방법입니다.** 질문 하나를 검색할 때마다 ✔ 또는 ✘를 하나 매기고, 24개 질문에서 ✔가 몇 개인지 셉니다. 세 지표는 **같은 검색 결과**를 서로 다른 기준으로 채점합니다.
|
||||
|
||||
- **doc** = 맞는 **문서**인가 (어느 규정에서 왔나만 봄)
|
||||
- **answer** = 답 **문구**가 들어 있나 ("5영업일" 같은 글자가 청크 안에 있나)
|
||||
- **@1, @3** = 위에서 **몇 등까지** 보나 (@1은 1등 하나만, @3은 1~3등 중 하나라도)
|
||||
|
||||
### 1.1 직접 채점해 보기 (섹션 청크, 2026-10-22)
|
||||
|
||||
질문 A **"비밀번호는 몇 자 이상이어야 하나요?"** 정답: 문서 `password-policy`, 답 문구 "12자"
|
||||
|
||||
| 순위 | 문서 · 섹션 | 점수 | 맞는 문서? | "12자" 있나? |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | `password-policy` · 1. 비밀번호 만들기 | 0.748 | ✔ | ✔ |
|
||||
| 2 | `password-policy` · 2. 변경 주기 | 0.54 | ✔ | |
|
||||
| 3 | `password-policy` · 3. 로그인 실패와 잠금 | 0.484 | ✔ | |
|
||||
|
||||
→ doc@1 ✔ (1등이 맞는 문서) · answer@1 ✔ (1등에 "12자") · answer@3 ✔
|
||||
|
||||
질문 B **"회사를 그만두면 노트북은 언제까지 돌려줘야 하나요?"** 정답: 문서 `device-issue-return`, 답 문구 "5영업일"
|
||||
|
||||
| 순위 | 문서 · 섹션 | 점수 | 맞는 문서? | "5영업일" 있나? |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | `device-issue-return` · 1. 지급과 교체 | 0.464 | ✔ | |
|
||||
| 2 | `device-issue-return` · 3. 반납 | 0.45 | ✔ | ✔ |
|
||||
| 3 | `device-issue-return` · 2. 분실과 도난 | 0.369 | ✔ | |
|
||||
|
||||
→ doc@1 ✔ (1등이 맞는 문서) · answer@1 **✘** (1등에는 "5영업일"이 없음) · answer@3 ✔ (2등에 있음)
|
||||
|
||||
질문 C **"챗GPT에 회의록 붙여 넣어도 돼요?"** 정답: 문서 `software-usage` (3. 생성형 AI 서비스), 답 문구 "입력하지 않는다"
|
||||
(24문항이 아니라 Lab 03 과제의 어려운 질문입니다. 같은 섹션 청크로 질문 다시 쓰기 없이 잼. 답 문구는 이 예를 위해 원문 "고객 정보, 개인정보, 대외비 문서는 생성형 AI 서비스에 입력하지 않는다."에서 고름)
|
||||
|
||||
| 순위 | 문서 · 섹션 | 점수 | 맞는 문서? | "입력하지 않는다" 있나? |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | `meeting-room` · 3. 사용 후 | 0.276 | ✘ | |
|
||||
| 2 | `privacy` · 2. 이용과 보관 | 0.259 | ✘ | |
|
||||
| 3 | `email-and-documents` · 2. 첨부 파일 | 0.259 | ✘ | |
|
||||
|
||||
→ doc@1 **✘** (1등이 회의실 규정) · answer@1 **✘** · answer@3 **✘** (맞는 문서가 3등 안에도 없음)
|
||||
|
||||
"회의록"이라는 낱말 때문에 회의실 규정이 1등이 됐고, 질문의 핵심인 "챗GPT"(규정은 "생성형 AI 서비스")는 잡지 못했습니다. 1등 점수도 0.276이라 2단계의 관련도 기준(0.33)에서 담당자 연결로 갑니다. doc@1이 ✘이면 answer 두 지표도 거의 늘 ✘입니다. 맞는 문서를 못 찾으면 답 문구도 없기 때문입니다. 4절에서 질문 다시 쓰기로 이 질문을 고칩니다.
|
||||
|
||||
질문 B는 지표마다 결과가 다릅니다. 이것이 지표를 셋이나 두는 까닭입니다.
|
||||
|
||||
| 지표 | 이 지표가 ✔이면 말할 수 있는 것 |
|
||||
| --- | --- |
|
||||
| doc@1 | 출처로 붙일 **규정은 맞게** 찾았다 |
|
||||
| answer@1 | **1등 하나만** LLM에게 줘도 답할 수 있다 |
|
||||
| answer@3 | 지금 Q&A처럼 **3개를 주면** LLM이 답할 수 있다 |
|
||||
|
||||
24개 질문 모두에 이렇게 매겨서 "24개 중 몇 개"로 적습니다. 섹션 청크의 결과는 doc@1 24 · answer@1 22 · answer@3 24입니다 (질문 B가 answer@1에서 틀린 두 개 중 하나).
|
||||
|
||||
### 1.2 테스트 파일이 채점하는 법
|
||||
|
||||
| 지표 | 묻는 것 | 테스트 파일 | 테스트가 보는 칸 |
|
||||
| --- | --- | --- | --- |
|
||||
| doc@1 | 1등 청크가 **맞는 문서**에서 왔나 | `retrieval-doc.json` | `hits.0.source` = 기대 문서 |
|
||||
| answer@1 | 1등 청크에 **답 문구**가 있나 | `retrieval-answer.json` | `hits.0.text`에 "12자", "90일" … |
|
||||
| answer@3 | 3등 안에 답 문구가 있나 | `retrieval-answer3.json` | `hits`(3개) 어딘가에 답 문구 |
|
||||
|
||||
- 질문 24개, 문서 8개. 각 질문의 정답(문서, 답 문구)은 Lab 01 예제 1처럼 사람이 정했습니다.
|
||||
- 결과는 "24개 중 몇 개"입니다. 퍼센트로 바꾸지 않고 **몇 개 중 몇 개**로 말합니다 (24개에서 하나는 4%나 됩니다).
|
||||
|
||||
### 1.3 세 지표가 말해 주는 것
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
D{"doc@1 ✔?"} -->|아니오| W1["다른 문서가 1등<br/>→ 낱말 · 뜻이 다른 문서와 가까움"]
|
||||
D -->|예| A1{"answer@1 ✔?"}
|
||||
A1 -->|예| OK["1등만 줘도 답할 수 있음"]
|
||||
A1 -->|아니오| A3{"answer@3 ✔?"}
|
||||
A3 -->|예| W2["같은 문서의 다른 섹션이 1등<br/>→ 3개를 주면 LLM이 답할 수 있음"]
|
||||
A3 -->|아니오| W3["답이 3등 밖<br/>→ LLM도 답할 수 없음"]
|
||||
```
|
||||
|
||||
doc@1은 맞는데 answer@1이 틀리면 **맞는 문서의 다른 섹션**이 1등입니다. LLM에 3개를 주는 지금 설정에서는 answer@3이 "답할 수 있는지"를 말해 줍니다.
|
||||
|
||||
### 1.4 answer@1에서 틀린 두 질문 들여다보기 (섹션 청크)
|
||||
|
||||
섹션 청크의 answer@1은 24개 중 **22개**입니다. 틀린 두 개가 무엇이고 왜 틀렸는지 봅니다. 두 날(10/18, 10/22) 모두 같은 두 질문이 틀렸습니다.
|
||||
|
||||
**① 무엇이 틀렸나: 1등과 2등의 점수가 거의 같다**
|
||||
|
||||
| 질문 | 1등 (답 없음) | 2등 (**답이 있는 섹션**) | 점수 차이 |
|
||||
| --- | --- | --- | --- |
|
||||
| 회사를 그만두면 노트북은 언제까지 돌려줘야 하나요? (1.1의 질문 B) | 장비 · 1. 지급과 교체 0.464 | 장비 · 3. 반납 0.45 ("5영업일") | 0.014 |
|
||||
| 고객 정보가 밖으로 샌 것 같아요 | 개인정보 · 2. 이용과 보관 0.395 | 개인정보 · 3. 유출 대응 0.375 ("1시간") | 0.02 |
|
||||
|
||||
둘 다 **문서는 맞았습니다** (doc@1 ✔). 같은 문서 안에서 답이 있는 섹션이 아주 작은 차이로 2등이 됐을 뿐입니다. 0.014는 1단계 2.4절에서 본 "실행마다 흔들리는 폭"(셋째 자리)보다 조금 큰 정도라, 질문을 조금만 바꿔도 순서가 뒤집힐 수 있습니다. 그래서 "아슬아슬"입니다.
|
||||
|
||||
**② 왜 틀렸나: 질문에 나온 낱말이 어느 섹션에 있나**
|
||||
|
||||
질문마다 원 질문, 질문이 정말 묻는 것, 1등 · 2등 섹션의 원문을 차례로 봅니다. **굵은 글자**가 질문과 섹션에 똑같이 나오는 낱말입니다.
|
||||
|
||||
질문 1. "회사를 그만두면 **노트북**은 언제까지 돌려줘야 하나요?"
|
||||
|
||||
- 질문이 정말 묻는 것: 퇴사할 때 **반납** 기한 → 답은 3절 "5영업일"
|
||||
|
||||
| 순위 | 섹션 | 점수 | 원문 | 질문과 같은 낱말 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1등 | 1. 지급과 교체 | 0.464 | 업무용 **노트북**은 입사일에 지급한다. **노트북** 교체 주기는 4년이다. | "노트북" 2번 |
|
||||
| 2등 (답) | 3. 반납 | 0.45 | 퇴사하거나 장비를 교체할 때는 5영업일 이내에 장비를 IT 담당자에게 반납한다. | 없음 ("노트북" 대신 "장비") |
|
||||
|
||||
질문 2. "**고객** 정보가 밖으로 샌 것 같아요"
|
||||
|
||||
- 질문이 정말 묻는 것: 개인정보 **유출** 때 할 일 → 답은 3절 "1시간 이내 신고"
|
||||
|
||||
| 순위 | 섹션 | 점수 | 원문 | 질문과 같은 낱말 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1등 | 2. 이용과 보관 | 0.395 | **고객** 개인정보가 보이는 화면은 캡처하거나 촬영하지 않는다. | "고객" |
|
||||
| 2등 (답) | 3. 유출 대응 | 0.375 | 개인정보가 유출되었거나 유출이 의심되면 1시간 이내에 보안팀에 신고한다. | 없음 ("밖으로 샌" 대신 "유출") |
|
||||
|
||||
두 질문 모두 같은 모양입니다.
|
||||
|
||||
- 1등 섹션에는 질문에 나온 **명사가 그대로** 있지만, 질문이 묻는 내용(반납, 유출)은 없습니다.
|
||||
- 2등 섹션에 답이 있지만, 질문과 **다른 낱말**("장비", "유출")로 쓰여 있습니다.
|
||||
- 그래서 임베딩이 1등 섹션을 아주 조금 더 가깝게 본 것으로 보입니다. 원문과 점수를 보고 한 해석이고, 원인을 따로 실험해 재지는 않았습니다.
|
||||
|
||||
**③ 그래서 어떻게 되나: 3개를 주면 답은 맞는다**
|
||||
|
||||
answer@3은 두 질문 모두 ✔입니다 (답이 2등에 있으니까). 2단계 Q&A는 발췌 3개를 LLM에게 주므로, 실제로 "회사를 그만두면 노트북은?"에 "퇴사 후 5영업일 이내에 … 반납해야 합니다"라고 맞게 답했습니다 (Lab 02 `lab02.json`, 2026-10-22).
|
||||
|
||||
| 이런 틀림이 문제가 되는 때 | 문제가 덜 되는 때 |
|
||||
| --- | --- |
|
||||
| 1등 하나만 쓰는 설계 (답 대신 "관련 규정 바로가기" 하나만 보여 주기 등) | 지금처럼 3개를 LLM에게 주는 Q&A |
|
||||
|
||||
4절의 질문 다시 쓰기는 "그만두면 → 퇴사"처럼 질문을 규정 낱말로 바꿔 이런 틀림을 줄입니다. 실제로 "노트북" 질문은 다시 쓰기 뒤 answer@1이 맞았습니다.
|
||||
|
||||
## 2. 재는 순서
|
||||
|
||||
**하고 싶은 것**: "청크를 섹션으로 자르는 것과 200자 · 400자로 자르는 것 중 어느 것이 검색을 잘하나?"를 숫자로 비교하기.
|
||||
|
||||
**원칙 두 가지**
|
||||
|
||||
1. **출발점(기준)을 먼저 잰다.** 지금 쓰는 설정(섹션)의 점수를 알아야 바꾼 뒤 좋아졌는지 나빠졌는지 압니다.
|
||||
2. **한 번에 하나만 바꾼다.** 청크 크기와 기준값을 함께 바꾸고 점수가 오르면, 무엇 때문에 올랐는지 모릅니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["① 기준 재기<br/>섹션"] --> B["② 하나만 바꾸기<br/>200자"] --> C["③ 같은 테스트로 다시"] --> D["④ 표에 한 줄"] --> B2["② 또 하나만<br/>400자"] --> C
|
||||
```
|
||||
|
||||
### 2.1 실제로 한 바퀴씩 (Lab 03 예제 1 · 2, 2026-10-22)
|
||||
|
||||
색인 워크플로우(`my-index`)는 요청 본문의 `chunking` 값을 보고 자르는 방식을 정합니다. 그래서 **워크플로우를 고치지 않고** 요청만 바꿔 다시 색인하면 됩니다.
|
||||
|
||||
| 바퀴 | 명령 | 하는 일 | 결과 |
|
||||
| --- | --- | --- | --- |
|
||||
| ① 기준 | `call my-index requests/index-section.json -v` | 섹션으로 다시 색인 (`{"chunking": "section"}`) | 청크 25개 |
|
||||
| | `test cases/retrieval-answer.json -v --no-before` | 지금 색인 그대로 24문항 채점 | answer@1 **22**/24<br>틀림: 퇴사 노트북, 고객 정보 유출 |
|
||||
| ② 200자 | `call my-index requests/index-200.json -v` | 200자로 다시 색인 (`{"chunking": 200}`) | 청크 20개 |
|
||||
| | `test cases/retrieval-answer.json -v --no-before` | 같은 24문항 다시 채점 | answer@1 **20**/24<br>틀림: VPN 인증서, 퇴사 노트북, 개인정보 파일 메일, 공짜 프로그램 |
|
||||
| ③ 400자 | `call my-index requests/index-400.json -v` | 400자로 다시 색인 | 청크 12개 |
|
||||
| | `test cases/retrieval-answer.json -v --no-before` | 같은 24문항 다시 채점 | answer@1 **22**/24<br>틀림: 개인정보 파일 메일, 화면 잠금 |
|
||||
|
||||
→ 바꾼 것은 매번 **청크 자르는 방식 하나**뿐이고, 채점은 매번 **같은 24문항**입니다. 그래서 22 → 20 → 22의 차이는 청크 크기 때문이라고 말할 수 있습니다.
|
||||
|
||||
섹션과 400자가 둘 다 22인 것은 **우연히 개수가 같을 뿐**입니다. 틀린 질문이 겹치지 않습니다: 섹션이 틀린 두 질문을 400자는 맞혔고, 섹션이 맞힌 다른 두 질문을 400자는 틀렸습니다. 그래서 숫자 옆에 **틀린 질문**을 함께 적습니다 (3.3절).
|
||||
|
||||
### 2.2 `--no-before`를 붙이는 까닭
|
||||
|
||||
케이스 파일에는 `before` 칸이 있어서, `test`는 원래 **채점 전에 섹션으로 다시 색인**합니다 (1단계 5절). 평소에는 편하지만, 여기서는 방금 200자로 해 둔 색인을 섹션으로 덮어써 버립니다.
|
||||
|
||||
| | 출력 첫 줄 | 실제로 잰 것 |
|
||||
| --- | --- | --- |
|
||||
| `--no-before`를 붙임 | (before 줄 없음) | 200자 색인 ✔ |
|
||||
| 빼먹음 | `✔ before: POST /webhook/my-index … {"indexed_chunks": 25, "chunking": "section"}` | **섹션** 색인 ✘ (200자를 쟀다고 착각) |
|
||||
|
||||
출력 첫 줄에 `before`가 있으면 다시 잽니다.
|
||||
|
||||
### 2.3 실험 기록 한 줄에 들어갈 것
|
||||
|
||||
| 칸 | 예 | 왜 |
|
||||
| --- | --- | --- |
|
||||
| 날짜 · 모델 | 2026-10-22, `text-embedding-3-large` | 모델이 바뀌면 숫자도 바뀜 |
|
||||
| 바꾼 것 하나 | 청크 섹션 → 200자 | 무엇의 효과인지 |
|
||||
| 청크 수 | 25 → 20 | 설정이 정말 적용됐는지 |
|
||||
| 지표 셋 | doc@1 24 · answer@1 20 · answer@3 24 (10/18에 셋 다 잼) | 좋아진 것과 나빠진 것 |
|
||||
| 틀린 질문 | "VPN 인증서", "공짜 프로그램" … | 숫자가 같아도 틀린 질문이 다를 수 있음 |
|
||||
| 보고서 | `runs/retrieval-answer-….json` | 다시 열어 볼 근거 |
|
||||
|
||||
`templates/RAG-EVAL-TEMPLATE.md` 4절이 이 표입니다. **틀린 질문** 칸을 빼먹기 쉽습니다 (3.3절).
|
||||
|
||||
## 3. 청크 크기
|
||||
|
||||
### 3.1 잰 표
|
||||
|
||||
| 설정 | 청크 수 | doc@1 | answer@1 | answer@3 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 섹션 | 25 | 24/24 | 22/24 | 24/24 |
|
||||
| 200자 | 20 | 24/24 | 20/24 | 24/24 |
|
||||
| 400자 | 12 | 22/24 | 22/24 | 24/24 |
|
||||
|
||||
(10/18 수업 준비. 10/22에는 섹션 지표 셋과 200자 · 400자 answer@1을 다시 재어 같은 값.)
|
||||
|
||||
- 우리 규정 문서는 짧아서(문서 하나에 섹션 2~4개, 526~928바이트) 400자로 자르면 청크가 오히려 **줄고** 섹션이 섞입니다. 청크 크기는 **내 문서 모양**을 보고 정합니다.
|
||||
- answer@3은 모두 24/24 → 3개를 주면 청크 크기 차이가 답에 덜 드러납니다. 대신 LLM에 주는 글이 길어집니다 (75일차 비용).
|
||||
|
||||
<details><summary>수강생이 "answer@3이면 다 맞으니 그걸로 되는 것 아닌가요?"라고 물으면</summary>
|
||||
|
||||
"이 24문항과 이 짧은 문서에서는 그렇습니다. 그래서 answer@3만 보면 안 됩니다."
|
||||
|
||||
| 까닭 | 근거 (오늘 잰 것) |
|
||||
| --- | --- |
|
||||
| 3개가 **전체에서 차지하는 몫**이 큼 | 섹션은 25개 중 3개(12%), 400자는 12개 중 3개(25%, 규정 전체의 4분의 1). 25개를 다 주면 answer@25는 늘 24/24지만 그건 검색을 안 한 것과 같음. 문서가 수천 개면 3개는 아주 작은 몫 |
|
||||
| 24문항은 **쉬운 쪽** | 모두 답이 있고 규정 낱말에 가까움. 어려운 질문 "챗GPT에 회의록 …"은 섹션에서도 맞는 문서가 3등 안에 없음 (1.1절 질문 C) |
|
||||
| 3등 안에 있어도 **Q&A가 답하지 못할 수 있음** | 400자 "화면 잠금"은 1등 점수 0.241 → 관련도 기준 0.33 아래라 LLM을 부르지 않고 담당자 연결. answer@3은 검색만 채점하고 기준값은 보지 않음 |
|
||||
| 많이 줄수록 LLM 일이 어렵고 비쌈 | 2단계 "노트북 사양"은 관련 없는 발췌(0.234 · 0.215)까지 출처로 붙임. 글이 길수록 시간 · 비용 (75일차) |
|
||||
|
||||
→ answer@3은 "3개를 주면 **답할 재료는 있다**", answer@1 · doc@1은 "검색이 **얼마나 정확한가**". 설정 사이의 차이는 answer@1 · doc@1에서 보입니다.
|
||||
</details>
|
||||
|
||||
### 3.2 200자: 문장이 잘린다
|
||||
|
||||
200자 색인에서 "VPN 인증서는 언제 다시 받아야 해요?"(답 "30일 전")가 answer@1을 틀렸습니다. 1등 청크(0.545)는 이렇게 시작합니다:
|
||||
|
||||
```text
|
||||
원격근무·VPN 이용 규정
|
||||
포털의 '인증서 재발급' 메뉴에서 새 인증서를 신청한다.
|
||||
- 인증서가 만료되면 VPN에 접속할 수 없으므로, 만료 전에 재발급한다.
|
||||
## 3. 재택근무 중 보안 …
|
||||
```
|
||||
|
||||
원래 문장은 "만료 **30일 전부터** IT 포털의 '인증서 재발급' 메뉴에서 새 인증서를 신청한다."입니다. 200자 경계가 이 문장 **한가운데**를 지나서, 앞부분("30일 전부터 … 새 인증서를")은 앞 청크(2등, 0.505)로, 뒷부분은 이 청크로 갔습니다. 답 문구가 1등 청크에 없습니다.
|
||||
|
||||
하나 더: 이 청크의 `section` 칸은 "3. 재택근무 중 보안"이었습니다. 청크 안의 첫 `## ` 제목을 섹션으로 붙이게 했기 때문에, 섹션 2의 뒷부분이 섹션 3 이름을 달았습니다. **글자 수로 자르면 출처 이름도 어긋날 수 있습니다.**
|
||||
|
||||
### 3.3 400자: 섹션이 섞인다
|
||||
|
||||
400자 색인은 청크 12개입니다. 원격근무 문서는 400자 안에 통째로 들어가서 **섹션 셋(접속 원칙 · VPN 인증서 · 재택근무 중 보안)이 모두 한 청크**가 됐습니다. 그 결과:
|
||||
|
||||
| 질문 (400자) | 1등 | 답("5분")이 든 청크 | 섹션 색인에서는 |
|
||||
| --- | --- | --- | --- |
|
||||
| 자리 비울 때 화면은 몇 분 뒤 잠기게 해요? | 회의실 · 1. 예약 **0.241** (틀림) | 원격근무 섹션 셋이 섞인 청크, **2등 0.236** | 원격근무 · 3. 재택근무 중 보안 1등 0.354 (맞음) |
|
||||
|
||||
여러 주제가 한 청크에 섞이면 그 청크의 벡터는 **어느 주제와도 덜 가깝게** 됩니다. "화면 잠금" 질문의 1등이 0.241로 규정 밖 질문의 점수대(0.20~0.26)까지 내려왔고, 엉뚱한 회의실 규정이 1등이 됐습니다. 답이 든 청크는 2등이라 answer@3은 ✔지만, 1등 점수가 0.241이라 2단계의 관련도 기준(0.33)에서 LLM을 부르지 않고 담당자 연결로 갑니다.
|
||||
|
||||
200자와 400자는 answer@1이 20 · 22로 섹션(22)과 비슷해 보이지만, 틀린 질문은 서로 다릅니다:
|
||||
|
||||
| 설정 | answer@1에서 틀린 질문 |
|
||||
| --- | --- |
|
||||
| 섹션 | 퇴사 노트북 (5영업일), 고객 정보 유출 (1시간) |
|
||||
| 200자 | VPN 인증서 (30일 전), 퇴사 노트북, 개인정보 파일 메일 (암호), 공짜 프로그램 (라이선스) |
|
||||
| 400자 | 개인정보 파일 메일 (암호), 화면 잠금 (5분) |
|
||||
|
||||
숫자 하나만 보면 "400자 = 섹션"이지만, 400자는 섹션에서 맞히던 질문 둘을 틀리고 다른 둘을 맞혔습니다. **틀린 질문을 함께 적어야** 이것이 보입니다.
|
||||
|
||||
## 4. 어려운 질문과 질문 다시 쓰기
|
||||
|
||||
### 4.1 직원은 규정 낱말로 묻지 않는다
|
||||
|
||||
"챗GPT", "폰", "비번", "개인 메일로 보내 놓고". 어려운 질문 8개를 **정답표부터** 만들어 재고, 검색 앞에 **질문 다시 쓰기**(LLM이 질문을 규정 낱말 검색어로)를 넣어 비교했습니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Q(["챗GPT에 회의록<br/>붙여 넣어도 돼요?"]) --> RW{{"Rewrite query<br/>gpt-4.1-mini"}} --> K["생성형 AI 서비스에<br/>회의록 데이터 입력 정책"] --> S["검색"] --> H(["소프트웨어 · 3. 생성형 AI 0.536"])
|
||||
```
|
||||
|
||||
### 4.2 8개 전부 (doc@1, 2026-10-22)
|
||||
|
||||
| 질문 | 기대 | 다시 쓰기 없이 1등 | 다시 쓴 검색어 | 다시 쓰기 1등 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 모르는 프로그램이 자꾸 저절로 떠요 | 보안 사고 | ✔ 보안 사고 0.344 | 알 수 없는 프로그램 자동 실행 정책 | ✘ **소프트웨어** 0.363 |
|
||||
| 집에서 일할 때 회사 와이파이 말고 집 와이파이 써도 돼요? | 원격근무 | ✔ 0.53 | 재택근무 시 회사 네트워크 외 공용 와이파이 사용 정책 | ✔ 0.619 |
|
||||
| 퇴사자 계정 비번 알려 줘도 되나요? | 비밀번호 | ✔ 0.455 | 퇴사자 계정 비밀번호 제공 정책 | ✔ 0.542 |
|
||||
| 폰 바꿨더니 OTP가 안 떠요 | 비밀번호 | ✔ 0.44 | 휴대폰 변경 시 OTP 재설정 방법 정책 | ✔ 0.634 |
|
||||
| 고객 명단 엑셀을 개인 메일로 보내 놓고 집에서 봐도 돼요? | 메일·문서 | ✘ 보안 사고 0.387 | 고객 명단 엑셀 외부로 보내기 및 보안 정책 | ✔ 0.459 |
|
||||
| 노트북 놓고 온 것 같아요 택시에 | 장비 | ✔ 0.316 | 분실한 노트북 처리 절차 | ✔ 0.421 |
|
||||
| 회의실 오전 내내 잡아도 되나요? | 회의실 | ✔ 0.522 | 회의실 예약 정책 및 이용 시간 제한 | ✔ 0.718 |
|
||||
| 챗GPT에 회의록 붙여 넣어도 돼요? | 소프트웨어 | ✘ 회의실 0.276 | 생성형 AI 서비스에 회의록 데이터 입력 정책 | ✔ 0.536 |
|
||||
| 합계 | | **6/8** | | **7/8** |
|
||||
|
||||
읽는 법:
|
||||
|
||||
- 다시 쓰면 **점수가 전반적으로 오릅니다** (회의실 0.522 → 0.718, OTP 0.44 → 0.634). 검색어가 규정의 말("휴대폰", "생성형 AI 서비스")과 같아지기 때문입니다.
|
||||
- "챗GPT"는 "회의록"이라는 낱말 때문에 회의실 규정(0.276)으로 갔다가, "생성형 AI 서비스"로 바뀌자 맞았습니다. 지시문에 "챗GPT·제미나이 → 생성형 AI 서비스"라는 예를 넣었기 때문입니다.
|
||||
- "모르는 프로그램이 자꾸 떠요"는 **새로 틀렸습니다.** "프로그램 자동 실행"이라는 검색어가 소프트웨어 **설치** 규정 쪽으로 갔습니다. 직원이 말한 것은 "감염된 것 같다"였는데, 다시 쓰기가 그 뜻을 지웠습니다.
|
||||
- "노트북 놓고 온 것 같아요 택시에"는 다시 쓰기가 "분실"이라는 핵심 낱말을 찾아 줬습니다 (0.316 → 0.421). 다시 쓰기 없이 0.316이면 관련도 기준(0.33) 아래라 담당자 연결로 갔을 질문입니다.
|
||||
|
||||
### 4.3 지시문을 고친 이야기 (수업 준비 때)
|
||||
|
||||
| 판 | 지시문의 예 | 결과 |
|
||||
| --- | --- | --- |
|
||||
| 1판 | "암호 → 비밀번호"처럼 예 하나 | "챗GPT"를 바꾸지 못함 → 검색어에 "챗GPT 사용 시 회의록 개인정보" |
|
||||
| 2판 (정답) | 그만두면 → 퇴사, 깔다 → 설치, 챗GPT·제미나이 → 생성형 AI 서비스, 개인 메일로 보내다 → 외부로 보내다·첨부 파일, 폰 → 휴대폰 | 위 표 7/8 |
|
||||
|
||||
2판은 **실패한 질문에서 찾은 낱말**을 넣었습니다. 시험 문제를 보고 답을 외운 것처럼, 이 8개에만 맞춘 것일 수 있습니다. 그래서 원래 24문항으로 **함께** 다시 쟀습니다:
|
||||
|
||||
| 24문항 | 다시 쓰기 없이 | 다시 쓰기 (10/18) | 다시 쓰기 (10/22) |
|
||||
| --- | --- | --- | --- |
|
||||
| doc@1 | 24 | 24 | 24 |
|
||||
| answer@1 | 22 | **24** | **23** |
|
||||
| answer@3 | 24 | 24 | 24 |
|
||||
| 검색 한 번 | 0.2~0.5초 | 0.9~1.6초 | 1.0~2.0초 |
|
||||
|
||||
다른 질문을 망가뜨리지 않았고(doc@1 · answer@3 그대로), 대신 검색마다 LLM을 한 번 더 불러 **1초쯤 느려졌습니다.**
|
||||
|
||||
### 4.4 어려운 질문을 만드는 법
|
||||
|
||||
| 방법 | 예 |
|
||||
| --- | --- |
|
||||
| 줄임말 · 외래어 | 비번, 폰, 챗GPT |
|
||||
| 상황으로 말하기 | "노트북 놓고 온 것 같아요 택시에" (= 분실) |
|
||||
| 두 규정에 걸치기 | "고객 명단 엑셀을 개인 메일로" (개인정보? 메일?) |
|
||||
| 다른 규정의 낱말이 섞임 | "챗GPT에 **회의록**" (회의실 규정으로 끌려감) |
|
||||
|
||||
처음 쓴 어려운 질문 하나는 "윈도우 업데이트 안 하고 미루면 안 돼요?"였습니다. 기대 문서를 `security-incident`로 적었는데, 규정에 윈도우 업데이트 이야기가 **없었습니다** (1등은 `software-usage` 0.309, 8개 중 5개 맞음. 자세히는 1단계 3.3절). 어려운 질문도 정답표부터, 원문을 열어 확인합니다. 답이 없는 질문은 검색 테스트가 아니라 2단계 답 검사 테스트로 보냅니다.
|
||||
|
||||
## 5. 같은 설정, 다른 결과
|
||||
|
||||
같은 정답 워크플로우로 10/22에 다시 재니, 다시 쓰기 뒤 answer@1이 **24 → 23**이 됐습니다.
|
||||
|
||||
| | 10/18 | 10/22 |
|
||||
| --- | --- | --- |
|
||||
| "고객 정보가 밖으로 샌 것 같아요"의 다시 쓴 검색어 | 고객 정보 외부 유출 **대응 방안** | 고객 정보 외부 유출 **방지 정책** |
|
||||
| 1등 | 개인정보 · 3. 유출 대응 0.559 ✔ | 개인정보 · 2. 이용과 보관 0.547 ✘ |
|
||||
| 2등 | 개인정보 · 2. 이용과 보관 0.487 | 개인정보 · 3. 유출 대응 0.51 |
|
||||
|
||||
- 검색 앞에 LLM을 두면 **검색도 매번 조금씩 달라집니다.** "대응"이 "방지"로 바뀌자 답 섹션이 2등으로 내려갔습니다.
|
||||
- 답이 3등 안에는 있어 answer@3은 그대로 24입니다. 2단계 Q&A는 3개를 주므로 답에는 영향이 적습니다.
|
||||
- 다시 쓰기를 넣었다면 `--repeat 3`으로 재고 "22~24"처럼 **범위**로 적습니다. 한 번 잰 24는 운이 좋았던 것일 수 있습니다.
|
||||
- LLM이 없는 검색(섹션 청크)은 두 날 모두 22로 같았습니다. 점수도 셋째 자리에서만 흔들립니다 (1단계 2.4절).
|
||||
|
||||
## 6. 무엇을 고를까
|
||||
|
||||
| 개선 | 좋은 점 | 대가 | 오늘 잰 것 |
|
||||
| --- | --- | --- | --- |
|
||||
| 청크를 뜻 단위로 (섹션) | 공짜, 가장 큰 차이일 때가 많음 | 문서에 구조가 있어야 함 | 섹션 22 vs 200자 20 (answer@1) |
|
||||
| 질문 다시 쓰기 | 구어체 · 다른 이름에 강함 | LLM 한 번 더 (약 1초, 비용), 새로 틀리는 질문, 실행마다 다름 | 어려운 8개 6 → 7, 24문항 answer@1 22 → 23~24 |
|
||||
| 같은 뜻 낱말표 (Code) | 빠르고 늘 같은 결과 | 표를 사람이 관리 | (재지 않음) |
|
||||
| `top_k` 늘리기 | answer@k가 오름 | LLM에 주는 글이 길어짐 | answer@1 22 → answer@3 24 |
|
||||
| 임베딩 모델 바꾸기 | 한국어에 맞는 모델이면 큰 차이 | 기준값도 다시 재야 함 | (재지 않음) |
|
||||
| 낱말 검색과 섞기 (BM25 + 임베딩) | 고유명사 · 숫자에 강함 | 섞는 비율을 또 재야 함 | (강사 바이브 코딩 거리) |
|
||||
|
||||
> 고르는 기준은 "어느 것이 좋다더라"가 아니라 **내 문서 · 내 질문으로 잰 숫자**입니다. 좋아진 것과 나빠진 것을 함께 적습니다.
|
||||
|
||||
### 6.1 언제 멈추나
|
||||
|
||||
- 정답표의 **중요한 질문**(자주 묻는 것, 틀리면 위험한 것)이 다 맞으면 멈춥니다. 24개 모두를 늘 맞히려고 지시문에 예를 계속 더하면, 그 24개에만 맞춘 검색이 됩니다.
|
||||
- 남은 실패는 **어디서 막는지** 적습니다: answer@3 안에 있으면 LLM이 답할 수 있고, 아니면 2단계의 기준값 · 답 검사가 담당자에게 넘기는지 확인합니다.
|
||||
- 새 질문이 들어오면 정답표에 더하고 다시 잽니다. 정답표는 한 번 쓰고 끝나는 것이 아니라 **함께 자랍니다** (77일차 지표, 79일차 골든 질문).
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. doc@1이 24/24인데 answer@1이 22/24입니다. 무엇이 문제인가요?</summary>
|
||||
|
||||
맞는 문서는 찾았지만 그 문서의 다른 섹션이 1등입니다 (예: "퇴사 노트북"은 지급 섹션 0.464, 반납 섹션 0.45). answer@3이 24/24라면 3개를 주는 Q&A는 답할 수 있습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. 200자로 바꿨는데 결과가 섹션과 똑같이 나왔습니다. 무엇을 의심하나요?</summary>
|
||||
|
||||
`--no-before`를 빼먹어 테스트의 `before`가 섹션으로 다시 색인했을 수 있습니다. 결과 첫 줄에 `✔ before:`가 있는지, `call my-index` 응답의 `indexed_chunks`가 20인지 확인합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. 400자의 answer@1이 22로 섹션과 같습니다. 400자를 써도 되나요?</summary>
|
||||
|
||||
숫자는 같지만 틀린 질문이 다릅니다 (400자는 "화면 잠금"을 0.241로 틀림). doc@1은 22로 더 나쁘고, 섞인 청크는 관련도 기준 아래로 떨어질 수 있습니다. 우리 문서에서는 섹션이 낫습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. 질문 다시 쓰기로 7/8이 됐습니다. 남은 1개를 맞히려면 지시문에 "모르는 프로그램 → 악성코드"를 넣으면 되나요?</summary>
|
||||
|
||||
그 질문은 맞겠지만 이 8개에 맞춘 것이 됩니다. 넣는다면 24문항과 다른 질문으로 함께 다시 재고, 새로 틀리는 것이 없는지 봅니다. 그리고 `--repeat`으로 여러 번 잽니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 다시 쓰기 뒤 answer@1이 24였다가 다음 날 23이 됐습니다. 무엇이 바뀌었나요?</summary>
|
||||
|
||||
워크플로우는 같습니다. LLM이 다시 쓴 검색어가 실행마다 달라 ("대응 방안" → "방지 정책") 1 · 2등이 바뀌었습니다. LLM이 검색 앞에 있으면 결과를 범위로 적습니다.
|
||||
</details>
|
||||
|
||||
## 정리
|
||||
|
||||
- [ ] doc@1 · answer@1 · answer@3을 같은 질문 목록으로. 세 지표의 조합으로 어디서 틀렸는지 읽는다
|
||||
- [ ] 한 번에 하나만 바꾸고, 표에 한 줄씩 (틀린 질문까지). `--no-before`를 확인한다
|
||||
- [ ] 청크 크기는 내 문서 모양을 보고. 글자 수는 문장을 자르고, 큰 청크는 주제를 섞는다
|
||||
- [ ] 개선 뒤에는 원래 테스트도 다시: 새로 틀린 것도 결과다
|
||||
- [ ] 검색 앞에 LLM이 있으면 결과가 실행마다 다르다 → 여러 번, 범위로
|
||||
@@ -0,0 +1,85 @@
|
||||
# 7·8교시 · 바이브 코딩 (`tdoc`)
|
||||
|
||||
- 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
|
||||
- 과제: [VIBE-REQ-TDOC](../../Last3Mon/71/VIBE-REQ-TDOC.md)(요청서) → 학생이 직접 쓰는 `SPEC.md` → [VIBE-Q-TDOC](../../Last3Mon/71/VIBE-Q-TDOC.md)(요구 · 단계)와 비교 → 만들기 → 수업 뒤 `VIBE-A-TDOC.md` 공개
|
||||
- 68 · 69일차와 같은 흐름입니다: 사람의 말(요청서)을 **확인할 수 있는 요구**로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다.
|
||||
- 오늘은 `tdoc`: 내 md 문서를 임베딩해 SQLite에 저장하고, 질문하면 답과 근거 문단을 보여 주는 RAG TUI. 설정을 바꿔 같은 질문 목록으로 비교합니다. 오늘 n8n으로 한 일을 내 문서에 직접.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
R["요청서 → SPEC<br/>10분"] --> A["7교시<br/>단계별 만들기 40분"] --> B["발표<br/>10분"] --> C["강사 정리<br/>10분"] --> D["강사 바이브 코딩<br/>15분"] --> E["보충 · 팁<br/>10분"] --> F["72일차 예고<br/>5분"]
|
||||
```
|
||||
|
||||
## 1. 7교시 · 각자 만들기 (50분)
|
||||
|
||||
| 시간 | 단계 | 확인 |
|
||||
| --- | --- | --- |
|
||||
| 16:00~16:02 | 0. 준비 (`~/vibe/tdoc`, `git init`, 키 환경 변수). **에이전트는 아직 켜지 않음** | |
|
||||
| 16:02~16:12 | 0. 요청서 → `SPEC.md` (직접) → VIBE-Q와 비교 · 고치기 · commit | 요구마다 확인 방법(호출 수 · 줄 수 · 맞은 수), 숨은 요구, 비교한 줄 |
|
||||
| 16:12~16:25 | 1. 색인 · 검색 (R1 · R2). 첫 요청은 "SPEC.md를 읽고 확인 방법부터 말해" | 두 번째 색인은 임베딩 0번, `tdoc search` |
|
||||
| 16:25~16:35 | 2. 답 · 근거 (R3) | 근거 번호, 점수 낮으면 LLM 없이 모른다고 |
|
||||
| 16:35~16:45 | 3. TUI · 비교 (R4 · R5) | `tdoc eval` 두 설정 |
|
||||
| 16:45~16:50 | 4. 정리 · `SPEC.md` 체크 · 발표 메모 | |
|
||||
|
||||
16:00에 화면에 띄울 것: 요청서의 ①~⑤와 예 하나(① → R1). "부탁은 확인할 수 없습니다. 호출 수 · 줄 수 · 맞은 수로 바꿉니다." 16:10쯤 "VIBE-Q를 열어 비교하세요"를 알립니다.
|
||||
|
||||
| 볼 것 | 막혔을 때 한마디 |
|
||||
| --- | --- |
|
||||
| 색인할 때마다 전부 다시 | "파일 해시로 바뀐 파일만" |
|
||||
| 테스트가 진짜 임베딩을 부름 | "가짜 임베딩으로" |
|
||||
| 근거 없이 답함 | "발췌로만, 번호로, 점수 낮으면 LLM 부르지 않기 — 오늘 Lab 02" |
|
||||
| 비교 없이 "잘 되는 것 같아요" | "질문 5개 정답표를 먼저" |
|
||||
| SPEC 없이 VIBE-Q를 통째로 붙여 넣었나 | "요청서로 SPEC.md부터. 확인 방법이 없으면 됐는지 모릅니다" |
|
||||
| SPEC에 부탁만 ("빠르게", "지어내지 않게") | "다시 색인하면 임베딩이 몇 번 불려야 하나요? 숫자로" |
|
||||
| 실행해 보지 않고 다음 요청 | "에이전트가 됐다고 해도 직접 `uv run tdoc`" |
|
||||
|
||||
수업 준비 때 tdoc를 미리 만들어 보지는 않았습니다. 강사 바이브 코딩(4절)에서 걸린 시간을 재어 정답본(`VIBE-A-TDOC.md`)에 남깁니다.
|
||||
|
||||
## 2. 8교시 · 발표 (10분)
|
||||
|
||||
- 1~2명. **두 설정을 숫자로 비교한 사람**을 먼저 고릅니다.
|
||||
- 3분 발표 · 2분 질문: **내 SPEC과 VIBE-Q가 달랐던 곳** / 잘 먹힌 요청문 / 안 먹힌 요청문 / 에이전트가 틀린 곳 / 교안 폴더에 질문 하나와 비교 표.
|
||||
|
||||
## 3. 강사 정리 (10분)
|
||||
|
||||
| | n8n 규정 Q&A | tdoc |
|
||||
| --- | --- | --- |
|
||||
| 저장소 | n8n 메모리 (재시작에 지워짐) | SQLite 파일 (남음) |
|
||||
| 다시 색인 | 매번 전부 (`clearStore`) | 바뀐 파일만 (해시) |
|
||||
| 검색 | Vector Store 노드 | 코사인 유사도 직접 |
|
||||
| 근거 | `[번호]` → 제목, `cited` | `[번호]` → 파일 · 섹션 |
|
||||
| 모르면 | 기준값 + 답 검사 | `--min-score` + 같은 생각 |
|
||||
| 품질 재기 | `retrieval-*` 24문항 | `tdoc eval questions.yaml` |
|
||||
|
||||
## 4. 강사 바이브 코딩 (15분)
|
||||
|
||||
| 주제 | 요청문 요지 | 보여 줄 것 |
|
||||
| --- | --- | --- |
|
||||
| 오늘 정답표로 eval | "Last3Mon/71/cases/retrieval-doc.json 을 읽어 tdoc eval 형식으로 바꿔 data-api/data/docs 에 돌려" | n8n과 tdoc을 같은 24문항으로 비교 |
|
||||
| 낱말 + 뜻 섞어 찾기 | "BM25 점수와 임베딩 점수를 섞어(가중치 옵션) 순위" | 3단계 "같은 뜻 낱말표"의 다른 방법 |
|
||||
| n8n에서 부르기 | "tdoc serve: /ask 웹훅처럼 POST 받는 작은 HTTP 서버" | 72일차 이후 n8n 워크플로우의 Tool로 |
|
||||
|
||||
걸린 시간과 결과를 `Last3Mon/71/VIBE-A-TDOC.md`에 적어 둡니다.
|
||||
|
||||
## 5. 보충 · 팁 (10분)
|
||||
|
||||
| 팁 | 설명 |
|
||||
| --- | --- |
|
||||
| 요청서 → 요구가 먼저 | 확인 방법(호출 수 · 줄 수 · 맞은 수)이 있는 요구가 있어야 에이전트의 "완료"를 판단할 수 있음 |
|
||||
| 정답표가 먼저 | 검색 품질은 "몇 개 중 몇 개"로 |
|
||||
| 한 번에 하나만 | 청크, top_k, 모델, 기준값을 따로 |
|
||||
| 바뀐 것만 다시 | 해시로 색인 시간·비용 절약 |
|
||||
| 근거는 코드가 확인 | 번호 범위, 숫자, 겹침 |
|
||||
| 비밀은 환경 변수 | 키는 DB·로그에 남기지 않기 |
|
||||
|
||||
## 6. 72일차 예고 (5분)
|
||||
|
||||
- 오늘: 검색 품질. 내일: **실행 흐름 최적화** — 워크플로우의 어디가 느린지 재고(p50·p95, 단계별 시간), 규칙 먼저·캐시·LLM 호출 줄이기로 빠르게 만들고, 빨라진 만큼 품질이 그대로인지 확인합니다. 데이터 API나 LLM이 멈춰도 정해진 답을 하게 합니다.
|
||||
- 바이브 코딩: `tbench` (URL·웹훅을 N번 호출해 응답 시간 p50·p95, 실패 수를 표와 스파크라인으로). 66일차 `turl` 요청을 그대로 가져와 씁니다.
|
||||
|
||||
## 확인 (강사)
|
||||
|
||||
- [ ] 7교시 시작 전 `OPENAI_API_KEY` 꺼내는 명령을 화면에 띄웠다 (키 값은 띄우지 않음).
|
||||
- [ ] 발표자 1~2명, 강사 정리 표, 강사 바이브 코딩 1개(시간 기록), 팁, 예고.
|
||||
- [ ] 16:00 요청서 → SPEC 10분을 지켰다 (에이전트 없이), 16:10 VIBE-Q 비교 알림.
|
||||
- [ ] 수업 뒤: `VIBE-A-TDOC.md`의 "자주 빠뜨리는 것"·강사 바이브 코딩 시간을 채우고 **학생 저장소에 VIBE-A만** 올린다 (LAB-A는 올리지 않음).
|
||||
@@ -0,0 +1,39 @@
|
||||
# 71일차 · RAG 기반 검색·응답 Workflow와 검색 품질 개선 (바이브 코딩)
|
||||
|
||||
- 일자: 2026-10-23 (71일차)
|
||||
- 교과목: 노코드 멀티 에이전트 워크플로우 설계 및 운영
|
||||
- 단원: 운영·확장 관점의 AI 워크플로우 설계 고도화
|
||||
- 학습 내용: RAG 기반 검색·응답 Workflow 구현, 검색 품질 개선 적용
|
||||
- 실습 폴더: [Last3Mon/71](../../Last3Mon/71/README.md)
|
||||
- 실습 환경: 65일차 n8n 2.42.6 + OpenAI API(`gpt-4.1-mini`, 임베딩 `text-embedding-3-large`) + 71일차 데이터 API(규정 문서) + **CLI 코딩 에이전트**
|
||||
- **실습 준비: [00-DAY71-PREP.md](00-DAY71-PREP.md) (수업 전날까지 1~2절 완료)**
|
||||
|
||||
## 오늘의 시간표
|
||||
|
||||
| 교시 | 시간 | 내용 | 자료 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | 09:00~09:50 | 오늘의 개요 · 1단계 · RAG와 색인 | [개요](00-DAY71-OVERVIEW.md), [1단계](01-STAGE1-RAG-AND-INDEX.md) |
|
||||
| 2 | 10:00~10:50 | 1단계 · Lab 01 (정답표, 색인·검색, 과제: 섹션 출처) | [Lab 01](../../Last3Mon/71/LAB-01-Q-INDEX-AND-SEARCH.md) |
|
||||
| 3 | 11:00~11:50 | 2단계 · 근거로 답하는 RAG 워크플로우, Lab 02 예제 1·2 | [2단계](02-STAGE2-RAG-ANSWER.md), [Lab 02](../../Last3Mon/71/LAB-02-Q-ANSWER-FROM-POLICIES.md) |
|
||||
| 4 | 12:00~12:50 | 2단계 · Lab 02 과제 35분 (점수는 높은데 답이 없을 때) · 풀이 | [Lab 02](../../Last3Mon/71/LAB-02-Q-ANSWER-FROM-POLICIES.md) |
|
||||
| - | 13:00~14:00 | 점심 | |
|
||||
| 5 | 14:00~14:50 | 3단계 · 검색 품질 측정과 개선, Lab 03 예제 1·2 | [3단계](03-STAGE3-RETRIEVAL-QUALITY.md), [Lab 03](../../Last3Mon/71/LAB-03-Q-MEASURE-AND-IMPROVE.md) |
|
||||
| 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (어려운 질문으로 고치기) · 풀이 | [Lab 03](../../Last3Mon/71/LAB-03-Q-MEASURE-AND-IMPROVE.md) |
|
||||
| 7 | 16:00~16:50 | 바이브 코딩 · `tdoc` 만들기 (각자, 요청서 → SPEC 먼저) | [VIBE-REQ-TDOC](../../Last3Mon/71/VIBE-REQ-TDOC.md) → [VIBE-Q-TDOC](../../Last3Mon/71/VIBE-Q-TDOC.md), [진행](04-VIBE-CODING.md) |
|
||||
| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 72일차 예고 | [진행](04-VIBE-CODING.md) |
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P["개요"] --> S1["1단계<br/>정답표 · 색인 · 검색"] --> S2["2단계<br/>근거로 답 · 넘기기 · 답 검사"] --> S3["3단계<br/>재기 · 한 가지씩 고치기"] --> V["7·8교시<br/>바이브 코딩 tdoc"]
|
||||
```
|
||||
|
||||
## 자료 목록
|
||||
|
||||
| 파일 | 내용 |
|
||||
| --- | --- |
|
||||
| `00-DAY71-PREP.md` | 실습 준비: n8n · 71일차 판 데이터 API 켜기, `flow.py doctor` (수업 전) |
|
||||
| `00-DAY71-OVERVIEW.md` | 개요 23장 (PPT 대신 Markdown, 가로줄로 장 구분): 앞 일차와의 연결, 오늘의 문서, 단계마다 실측 장 |
|
||||
| `01-STAGE1-RAG-AND-INDEX.md` | 왜 RAG인가(네 가지 방법 비교), 임베딩과 점수 읽기(실측), 정답표 먼저(질문 종류 · 정답표도 틀림), 청크 하나의 모양 · 메타데이터, 메모리 저장소의 한살이, 요청문 좋은 예 · 나쁜 예, 확인 질문 |
|
||||
| `02-STAGE2-RAG-ANSWER.md` | LLM이 받는 발췌의 실제 모양 · 실측 답, `sources`와 `cited`, 관련도 기준 10개 · 정하는 순서 · 양쪽으로 틀림, 점수는 높은데 답이 없을 때, 답 검사 넷(계산 방법 · 결과 JSON), 넘기는 길 세 갈래, 확인 질문 |
|
||||
| `03-STAGE3-RETRIEVAL-QUALITY.md` | doc@1 · answer@1 · answer@3(아슬아슬한 1등), 재는 순서 · 실험 기록, 청크 크기(잘린 문장 · 섞인 청크 · 틀린 질문이 다름), 어려운 질문 8개와 다시 쓴 검색어, 같은 설정 다른 결과, 개선 방법 고르기 · 멈출 때, 확인 질문 |
|
||||
| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tdoc), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
|
||||
Reference in new issue
Block a user