Si el corpus es un activo estático que se construye una vez y luego se termina, esta sección puede ser breve. Sin embargo, en entornos que manejan datos cambiantes (planes de servicios de empresas de TI, bases de conocimiento, documentos API, etc.), la gestión de la calidad del corpus se convierte en la parte más importante del proceso de RAG.
| categoría | explicación | ejemplo |
|---|---|---|
| Ausencia de información (Brecha) | No hay ningún tema en el corpus. | El plan de nuevas funciones de lanzamiento aún no se ha reflejado. |
| Información obsoleta | Información que antes era correcta pero ahora es incorrecta | El documento API v1 del año pasado permanece, pero actualmente es v2 |
| Redundancia de información | El mismo contenido se repite en múltiples fuentes. | Los documentos de planificación v1, v2 y v3 con la misma función existen en el corpus. |
Entre ellos, la corrupción de la información es la más peligrosa. La brecha se revela como "no hay resultados de búsqueda", pero la información corrupta es "resultados de búsqueda disponibles pero incorrectos", por lo que LLM da con seguridad la respuesta incorrecta.
Al agregar un nuevo documento, compárelo con el corpus existente por similitud de coseno:
# 신규 청크 vs 기존 청크 유사도 행렬
sim_matrix = new_embeddings @ existing_embeddings.T # (new × existing)
# 각 신규 청크의 최대 유사도가 threshold(0.92) 이상이면 중복
for i, row in enumerate(sim_matrix):
if row.max() >= 0.92:
dup_count += 1
Criterios de juicio:
duplicate (no agregar)partial (agregado después de la revisión)new (agregado inmediatamente)A medida que el corpus crece, es posible que se superpongan contenidos idénticos de diferentes fuentes:
python scripts/dedup.py --self-dedup data/chunks_meta.jsonl --threshold 0.95
Excluyendo fragmentos adyacentes (similitud natural debido a la superposición), solo informa una similitud superior a 0,95 entre diferentes archivos fuente.
En el entorno de una empresa de TI, los documentos se actualizan constantemente. Realizar una reconstrucción completa cada vez es ineficiente, por lo que se necesita la estrategia Actualización incremental:
Estrategia 1: sincronización incremental basada en marcas de tiempo
[변경 감지]
최종 동기화 시각 이후 수정된 문서만 추출
(Confluence: lastModified, Git: git log --since, 파일시스템: mtime)
│
▼
[기존 청크 제거]
해당 소스의 기존 청크를 chunks_meta.jsonl에서 삭제
│
▼
[신규 청킹]
변경된 문서만 chunk.py로 재처리
│
▼
[증분 인덱싱]
신규 청크만 임베딩 생성 → 기존 embeddings.npy에 append
BM25 인덱스는 전체 재구축 (in-memory 방식이므로 빠름)
Estrategia 2: Reemplazo basado en versiones
Si el documento tiene versiones (plan v1 → v2 → v3):
[신규 버전 감지]
v3 문서가 들어옴
│
▼
[이전 버전 청크 삭제]
source가 "기획서_v1", "기획서_v2"인 청크를 모두 제거
│
▼
[신규 버전 청킹 + 인덱싱]
v3만 코퍼스에 남김
Esto evitará estructuralmente el problema de la “corrupción de la información”. Mantenga las versiones anteriores en el archivo, pero exclúyalas de la búsqueda.
Estrategia 3: Vencimiento basado en el tiempo de vida
Establezca un TTL para documentos que cambian con frecuencia (informes semanales, planificación de sprints, etc.):
# 청크 메타데이터에 만료 시각 추가
{
"chunk_id": "sprint_plan_0001",
"source": "2026_Q1_sprint_plan.md",
"expires_at": "2026-04-01T00:00:00", # 분기 종료 시 만료
...
}
# 검색 시 만료된 청크 필터링
results = [r for r in results if r.get("expires_at", "9999") > now()]
Cómo detectar automáticamente cuando la información del corpus no coincide con la realidad:
Método 1: Búsqueda periódica de espacios (utilizado en este proyecto)
Defina un conjunto básico de consultas y recupérelas periódicamente para realizar un seguimiento de los cambios en la puntuación:
쿼리: "결제 API v3 엔드포인트"
- 1주 전 score: 0.85 (정상)
- 현재 score: 0.45 (급락) → 문서가 삭제되었거나 변경됨 → 알림
Método 2: bucle de comentarios del usuario
Cuando el bot basado en RAG responde "¿Te resultó útil?" Botón Agregar:
Método 3: validación cruzada
Cuando hay varias fuentes sobre el mismo tema y las respuestas se contradicen, marque:
소스 A: "결제 타임아웃은 30초"
소스 B: "결제 타임아웃은 60초"
→ 모순 감지 → 어느 것이 최신인지 확인 필요
Corpus inevitablemente se deteriora con el tiempo. Surgen nuevas preguntas, la información existente queda obsoleta y surgen áreas en blanco. Si esto lo gestionan manualmente las personas, es insostenible. El ciclo de “encontrar lagunas → llenar → verificar” debe automatizarse para que RAG mejore con el tiempo.
┌───────────────────────────────────────────┐
│ │
▼ │
Step 1: 갭 분석 │
(핵심 쿼리 배치 검색, score < 0.75 = 갭) │
│ │
▼ │
Step 2: 자료 수집 │
(수집 에이전트 병렬, 온라인 검증 소스만) │
│ │
▼ │
Step 3: 출처 검증 + 중복 검사 │
(출처 없는 파일 삭제, dedup.py) │
│ │
▼ │
Step 4: 인덱스 리빌드 │
(chunk.py → embed.py) │
│ │
▼ │
Step 5: 검증 (동일 쿼리 재검색) │
│ │
▼ │
Step 6: 수렴 판단 │
모든 쿼리 score ≥ 0.75? ──No──────────────────────┘
│
Yes
▼
수렴 완료
Condición de convergencia:
En el proyecto Saju, el método es “buscar y recopilar datos en línea”, pero en la empresa de TI, las fuentes de datos son diferentes:
| paso | Proyecto Saju | aplicación de empresa de TI |
|---|---|---|
| Detección de brechas | Búsqueda por lotes de 20 consultas clave | Recopile automáticamente consultas con puntuación <0,5 de los registros de consultas de los usuarios |
| Recopilación de datos | agente de búsqueda en línea | Programador de sincronización Confluence/Notion/Git |
| Verificación de fuente | Comprobar la presencia de URL | Verificar propietario del documento/fecha de última modificación |
| Inspección duplicada | Similitud del coseno 0,92 | Prevención de duplicados basada en ID de documentos + similitud de coseno |
| Reconstruir | Refragmentación completa + reintegración | Actualizaciones incrementales (solo cambios) |
| verificación | Investigar la misma consulta | Pruebas A/B (índice antiguo versus índice nuevo) |
Escenario específico: Plan de servicio RAG
[매일 02:00 크론잡]
↓
Confluence API로 최근 24h 내 수정된 페이지 목록 조회
↓
수정된 페이지: 기존 청크 삭제 → 신규 청킹 → 증분 임베딩
삭제된 페이지: 기존 청크 삭제
신규 페이지: 청킹 → 임베딩 → 추가
↓
BM25 인덱스 재구축 (in-memory라 30초 이내)
↓
검증 쿼리 셋 실행 → 이전 점수 대비 급락 항목 알림
La clave para el análisis de brechas es diseñar un conjunto bien diseñado de consultas esperadas: "Esta consulta debería producir buenos resultados":
// 이 프로젝트의 갭 쿼리 (20개)
[
"오행 상생상극 생극제화",
"지장간 투출 통근 격국",
"십성 식신 상관 정관 편관",
"용신 억부 조후 통관",
"궁합 천간합 오행 배합",
...
]
En un entorno de TI:
// 서비스 Knowledge Base 갭 쿼리 예시
[
"결제 API 타임아웃 설정값",
"iOS 앱 최소 지원 버전",
"신규 가입 프로모션 할인율",
"장바구니 상품 최대 개수",
"개인정보 보유 기간 정책",
...
]
Establezca umbral de puntuación esperado para cada consulta y verifíquelo periódicamente. Cuando se produce una consulta por debajo del umbral, es una señal de que los documentos en esa área son insuficientes o han cambiado.
사용자: "1990-05-15 14:30 남자 사주 봐줘"
│
▼
┌─────────────────────────────────┐
│ saju-analysis (오케스트레이터) │
│ Phase 1: saju.py 실행 → JSON │
│ Phase 2: 5개 서브에이전트 병렬 │
│ Phase 3: 결과 통합 → .md 출력 │
└─────────┬───────────────────────┘
│ Agent() × 5 (parallel)
┌─────┼─────┬──────┬──────┐
▼ ▼ ▼ ▼ ▼
saju- saju- saju- saju- saju-
profile structure dynamics fortune timeline
│ │ │ │ │
│ 각 에이전트가 search.py로 RAG 검색
│ (주제당 2~3개 쿼리, 총 ~30회 이내)
│ │ │ │ │
└─────┴─────┴──────┴──────┘
│
각자 원문 인용 기반 분석 작성
│
▼
오케스트레이터가 통합·중복 제거
│
▼
output/YYYY-MM-DD_이름_일주_사주.md
El análisis de compatibilidad (gunghap-analysis) tiene la misma estructura y ejecuta cinco subagentes (gunghap-mind-energy, gunghap-ilji, gunghap-destiny, gunghap-yongsin, gunghap-timeline) en paralelo. Tanto el análisis de cuatro semanas como el análisis de compatibilidad siguen el mismo protocolo de búsqueda RAG.
Cada subagente sigue las mismas reglas:
Comando de búsqueda:
.venv/bin/python scripts/search.py \
"갑목(甲木) 인월(寅月) 조후용신" \
"궁통보감(窮通寶鑑) 갑목 봄" \
"甲木 寅月 用神" \
--top-k 3 --mode hybrid --json
Estándares de uso de resultados:
score ≥ 0.6 → Alta confiabilidad. Asegúrate de citar el texto original.score 0.3~0.59 → Inclusión condicional (incluir si es el único resultado para ese tema)score < 0.3 → ExcluidoPrincipio de conservación del texto original:
El subagente no resume los resultados de la búsqueda y entrega el texto original tal cual. El orquestador se encarga de la interpretación. Esta separación garantiza la exactitud de la cotización de la central nuclear.