Un documento metodológico que analizó de forma inversa un proyecto de juguete creado para practicar directamente la construcción y utilización de un proceso RAG multilingüe.
La razón por la que se seleccionó Cuatro pilares de Myeongrihak (Cuatro pilares de caracteres chinos) como tema es que Cuatro pilares de Myeongrihak combina naturalmente análisis basados en estadísticas + textos originales en coreano, chino e inglés, lo que permite todas las cuestiones de fragmentación/incrustación/búsqueda multilingües se pueden experimentar en un solo proyecto.
Todos los experimentos y operaciones se realizaron en un entorno local (M1 Mac) y la canalización se completó sin dependencia de servicios externos.
Este documento consta de una descripción general y cuatro documentos detallados.
| documento | detalle | preguntas clave |
|---|---|---|
| Este documento (descripción general) | Glosario, antecedentes, panorama general de la arquitectura, principios de diseño | ¿Qué es RAG y por qué se creó así? |
| Parte 1: Recopilación de datos·limpieza·fragmentación | Capa de origen de datos, reglas de limpieza, estrategia de fragmentación e incorporación de descubrimiento de errores en el modelo | ¿Cómo se convierten los datos sin procesar en unidades de búsqueda? |
| Parte 2: Incrustación·Indexación·Búsqueda | Índice dual denso/BM25, búsqueda híbrida, ponderaciones adaptables, expansión de consultas multilingües | ¿Cómo se crea un índice y cómo funciona la búsqueda? |
| Parte 3: Gestión de corpus·Mejora automática·Agente | Tipos de degradación de corpus, estrategias de actualización, ciclos de enriquecimiento automático y utilización de agentes LLM. | ¿Cómo se mantiene actualizado el corpus y cómo lo utiliza LLM? |
| Parte 4: Expansión·Producción·Aplicación de TI | Escalado de 10K → 1M+, opciones de implementación paso a paso, aplicación de base de conocimientos para empresas de TI | ¿Cómo aplicamos esto a los servicios reales? |
Primero, resumimos los términos clave que aparecen repetidamente en este documento. Si está familiarizado con RAG o conceptos de incrustación, puede omitir esto.
Una técnica en la que un modelo de lenguaje a gran escala (LLM) primero busca documentos relacionados y hace referencia a sus contenidos antes de generar una respuesta. El LLM por sí solo tiene el problema de crear “alucinaciones” de conocimiento que falta o es inexacto en los datos de aprendizaje. RAG alivia este problema al obligarte a "responder según el texto original que buscaste".
일반 LLM: 사용자 질문 → LLM → 답변 (학습 데이터에 의존, 환각 위험)
RAG: 사용자 질문 → [검색] → 관련 문서 발견 → LLM + 문서 → 답변 (근거 있음)
Esto se refiere a toda la colección de documentos utilizada por RAG como objetivo de búsqueda. En este proyecto, 593 archivos PDF, Markdown y de texto relacionados con los Cuatro Pilares de Myeongri conforman el corpus. La calidad y el alcance del corpus determinan el límite superior del desempeño de RAG. Por muy bueno que sea el algoritmo de búsqueda, si la información no existe en el corpus, no se podrá encontrar.
El proceso de dividir un documento extenso en unidades más pequeñas (fragmentos) adecuadas para la búsqueda. Si busca en un libro completo (decenas de miles de caracteres), no puede saber qué partes están relacionadas, por lo que lo divide en unidades significativas de aproximadamente 300 a 500 caracteres y convierte cada una en un objetivo de búsqueda independiente. Si lo corta demasiado grande, la precisión de la búsqueda disminuirá y si lo corta demasiado pequeño, se perderá el contexto.
Conversión de texto a un vector numérico (una matriz de cientos de números decimales). La frase “El carácter de Gapmok es heterosexual y fuerte” se convierte en una matriz de 384 números como [0.12, -0.34, 0.56, ...]. Dado que oraciones con significados similares tienen vectores similares, la similitud semántica se puede comparar numéricamente calculando la distancia entre vectores. Este es el principio de "búsqueda de significado".
Algoritmo tradicional de búsqueda basada en palabras clave. La puntuación se calcula combinando cuántas veces aparece la palabra de consulta en el documento (TF) y qué tan rara es la palabra (IDF). Si busca "甲木", encontrará documentos que contienen la palabra exacta "甲木". Si se busca "significado" en incrustación, se busca "letras" en BM25. La combinación de los dos (búsqueda híbrida) compensa las debilidades de cada uno.
Un método para determinar la clasificación final suma los resultados de BM25 (coincidencia de palabras clave) y Dense Embedding (búsqueda semántica). Por ejemplo, si busca "personalidad de Gapmok":
Después de seleccionar candidatos mediante la primera búsqueda, la **búsqueda de segunda etapa los reclasifica con un modelo más preciso. El primero (BM25+Dense) es rápido pero tosco, y el segundo (Cross-Encoder) es lento pero preciso. Debido a que las consultas y los documentos se ingresan simultáneamente y la relevancia se juzga directamente, la clasificación es mucho más precisa que la búsqueda primaria. Sin embargo, debido a que es demasiado lento para aplicar a todo el corpus, se seleccionan de 20 a 40 candidatos en la primera ronda y se aplican solo a estos.
Encontrar el vector más cercano calculando la distancia (similitud) entre los vectores integrados. En este proyecto, se calcula el producto escalar del vector de 9586 fragmentos y el vector de consulta. A medida que aumenta la escala, la velocidad se garantiza mediante la búsqueda aproximada del vecino más cercano (ANN) utilizando bases de datos vectoriales dedicadas como FAISS y Pinecone.
Establecer el valor para devolver solo los K principales en los resultados de búsqueda. Si es top-k 5, solo se recuperan los cinco fragmentos más relevantes. Si K es demasiado pequeño, se pierde información relevante y si K es demasiado grande, el LLM se confunde con ruido irrelevante. En este proyecto, top-k 5 se utiliza como valor predeterminado para la búsqueda única CLI y top-k 3 para la búsqueda por lotes RAG.
Una herramienta para separar texto en unidades simbólicas (palabra/morfema) con capacidad de búsqueda. El coreano requiere un análisis morfológico para separar "Cuatro pilares de Myeongri" en "Cuatro pilares/Myeongri/Hak", el chino no tiene espacios, por lo que "Cuatro pilares y ocho caracteres" deben segmentarse en "Cuatro pilares/八字", y el inglés se resuelve principalmente dividiendo por espacios. La calidad de búsqueda de BM25 aumenta sólo cuando se utiliza un tokenizador apropiado para cada idioma.
LLM, al igual que Saju Myeongrihak, tiene graves alucinaciones en conocimiento profesional sistemático pero no convencional. Si le preguntas: “¿Qué es el Dios Dragón cuando Gapmok (甲木) Il-il nace en Inwol (寅月)?”, él da con confianza una respuesta plausible pero incorrecta. En áreas que requieren una interpretación precisa basada en textos clásicos (Jeokcheonsoo, Gungtongbogam), no se puede confiar en el LLM por sí solo.
Este no es sólo un problema de Saju Myeongrihak. El mismo problema ocurre en todos los dominios que no están suficientemente incluidos en los datos de aprendizaje de LLM, como los planes de servicio internos, la última API de un marco específico, precedentes legales y pautas médicas.
Saju Myeongnihak es un dominio inherentemente multilingüe:
| idioma | role | ejemplo |
|---|---|---|
| chino | Texto original/clásico | 滴天髓, 窮通寶鑑, 子平真詮 |
| coreano | Interpretación moderna, libros de texto y casos prácticos. | La teoría del reino de los cielos, la teoría del dragón, 100 frases prácticas |
| inglés | Artículos académicos/investigación de ML | Predicción de carrera de BaZi, simulación de personajes de IA |
Una consulta "Gapmok Inwol Yongshin" debe buscar libros de texto coreanos, texto original chino 窮通寶鑑 y artículos en inglés simultáneamente para formar una respuesta completa. Esto es estructuralmente lo mismo que la situación en la que una empresa de TI debe realizar una búsqueda integrada de documentos técnicos en inglés + documentos de planificación coreanos + documentos API de socios japoneses.
┌─────────────────────────────────────────────────────────┐
│ 0단계: 데이터 수집·정제 │
│ 원본 PDF/MD/TXT → 구조화 마크업 (--- 구분선, 출처 표기) │
│ 중복 검사 → 출처 검증 → books/ 디렉토리에 배치 │
│ → 상세: Part 1 │
└───────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 1단계: 청킹 (chunk.py) │
│ PDF→PyMuPDF / TXT→직접 읽기 │
│ 언어 감지 → 단락 경계 존중 → 512자 청킹 (64자 overlap) │
│ 출력: chunks.jsonl (9,586개 청크, 4.16MB) │
│ → 상세: Part 1 │
└───────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 2단계: 인덱싱 (embed.py) │
│ │
│ ┌──────────────────┐ ┌──────────────────────┐ │
│ │ Dense Embedding │ │ BM25 Sparse Index │ │
│ │ MiniLM-L12-v2 │ │ 한국어: Kiwi POS │ │
│ │ 384차원, L2 정규화 │ │ 중국어: jieba 분절 │ │
│ │ → embeddings.npy │ │ 영어: regex+stopwords │ │
│ │ (14MB) │ │ → bm25_index.pkl │ │
│ └──────────────────┘ └──────────────────────┘ │
│ → 상세: Part 2 │
└───────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3단계: 하이브리드 검색 (search.py) │
│ │
│ 쿼리 → 언어 감지 → 다국어 토큰 확장(한↔漢 143개 키) │
│ → BM25 top-K ∪ Dense top-K 후보 (K=max(20,top_k×4)) │
│ → (옵션) bge-reranker-v2-m3 리랭킹 │
│ → 소스 다양성 페널티 → top-K 반환 │
│ → 상세: Part 2 │
└───────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 4단계: LLM 에이전트 활용 + 코퍼스 관리 │
│ │
│ Claude Code Skill 오케스트레이터 │
│ → 5개 서브에이전트 병렬 실행 │
│ → 각 에이전트가 search.py로 RAG 검색 │
│ → 원문 인용 기반 분석 보고서 생성 │
│ → 자동 갭 분석 → 수집 → 리빌드 사이클 │
│ → 상세: Part 3 │
└─────────────────────────────────────────────────────────┘
| artículo | ojo morado |
|---|---|
| documento fuente | 593 (PDF + MD + TXT) |
| Número total de trozos | 9.586 |
| capacidad total de texto | Aproximadamente 4,16 millones de caracteres (tamaño de archivo chunks.jsonl 10,4 MB) |
| tamaño promedio del trozo | 434 caracteres |
| Incrustación densa | 9.586 × 384 flotante32 = 14 MB |
| Índice BM25 | 14,7 MB (bm25_index.pkl 7,1 MB + tokenized_corpus.pkl 7,6 MB) |
| distribución del idioma | Coreano 80,5% / Chino 14,2% / Inglés 5,3% |
Resumimos los principios que se han verificado en este proyecto y se pueden aplicar independientemente del dominio y la escala.
En dominios especializados, BM25 (palabra clave) + Denso (significado) deben usarse juntos. Lo denso por sí solo es peligroso en dominios con términos que requieren una coincidencia exacta de letras, como nombres propios, abreviaturas, nombres en clave, puntos finales de API, etc. Denso puede dar resultados extraños "semánticamente similares" y BM25 no puede encontrar nada sin las palabras clave exactas. Tienes que combinar los dos.
Si crea una tabla de sinónimos, abreviaturas y correspondencia multilingüe, su tasa de recuperación de búsqueda aumentará drásticamente. Un ejemplo es el mapeo Han ↔ Han de 143 claves (209 pares) en este proyecto. Si es un dominio legal, cree una tabla como "Acto ilegal ↔ Acto ilegal ↔ agravio", si es TI, es "K8s ↔ Kubernetes ↔ Kubernetes", y si es un dominio médico, es "Diabetes ↔ diabetes mellitus ↔ DM".
La fragmentación de tamaño fijo es sencilla, pero la calidad de la búsqueda se deteriora cuando se truncan las unidades semánticas. It is effective to use document structures such as --- separators or markdown headings (##) as atomic boundaries. Y para que esto funcione, los datos ya deben estar estructurados en la etapa de recopilación. La calidad de la fragmentación es un reflejo de la calidad de la limpieza de datos.
El proceso de dos etapas, que selecciona ampliamente candidatos con BM25+Dense en la Etapa 1 y los clasifica con precisión con Cross-Encoder en la Etapa 2, mejora significativamente la calidad de la búsqueda. Aunque el coste de volver a clasificar a 40 candidatos es insignificante, la mejora en la precisión es notable.
No hay corpus estático. “Gap detection → data collection/update → rebuild → verification” must be automated to maintain or increase quality over time. La gestión manual inevitablemente falla a escala.
Al transmitir los resultados de la búsqueda a LLM, no los resuma, sino transmita el texto original. La información se pierde o distorsiona durante el proceso de resumen. La exactitud de la cita se garantiza sólo cuando el LLM ve directamente el texto original y emite un juicio. Es por eso que los subagentes de este proyecto se ven obligados a "citar el texto completo".
| componente | Implementación de este proyecto. | Opciones de expansión de la producción | documentación detallada |
|---|---|---|---|
| Recopilación de datos | Manual + agente saju-investigador-recolector | API de Confluence, webhooks de Git, eventos de S3, Unstructured.io | Parte 1 |
| Limpieza de datos | --- Línea divisoria, fuente requerida, creación de IA prohibida |
Conversión HTML→MD, enmascaramiento de PII, gestión de versiones | Parte 1 |
| Chungking | 512 caracteres, 64 caracteres superpuestos, --- respeta los límites |
LangChain TextSplitter, fragmentación semántica | Parte 1 |
| Incrustar | MiniLM-L12-v2 (384d, local) | bge-m3, API de incrustación de OpenAI, incrustación de Cohere | parte 2 |
| BM25 | rango-bm25 (encurtido en memoria) | Elasticsearch, OpenSearch y Weaviate integrados | parte 2 |
| Búsqueda vectorial | producto escalar numeroso (14 MB npy) | FAISS, Piña, Qdrant, pgvector | parte 2 |
| Reclasificador | bge-reranker-v2-m3 (local) | Cohere Rerank, Jina Reranker, LLM Reranking | parte 2 |
| Expansión de consultas | 143 teclas (209 pares) Diccionario coreano-chino | WordNet, ontología de dominio y extensiones basadas en LLM | parte 2 |
| Gestión de corpus | Brecha automática→recolectar→ciclo de reconstrucción | Sincronización incremental, caducidad de TTL, bucle de retroalimentación del usuario | parte 3 |
| Agente | Habilidades del Código Claude (5+5 Paralelas) | Agente LangChain, Agente LlamaIndex | parte 3 |
| Escalada | numpy + pepinillo (9,6K trozos) | FAISS → Qdrant → Piña | parte 4 |
| Aplicación de TI | — | Planificación de RAG, robot KB, respuesta a fallos | parte 4 |
El valor central de este sistema es que se trata de un oleoducto RAG “pequeño pero completo”**. Este sistema, que consta de 593 documentos, 9586 fragmentos y 4 scripts de Python (chunk.py, embed.py, search.py, dedup.py), incluye búsqueda híbrida multilingüe, reclasificación, ponderación adaptativa y enriquecimiento automático del corpus.
Al ampliar, simplemente reemplace cada componente con la opción Producción en la tabla anterior. Los principios de diseño y la estructura de la tubería siguen siendo los mismos independientemente de la escala. Lo que cambia es la infraestructura, no la arquitectura.