Field Log · Entry
[RAG] Harness-1 확장 설계: ColBERT·Cross-Encoder·PPR은 어디에 붙일까?
Harness-1의 auto-seeding과 evidence graph를 더 강하게 만들려면 ColBERT, Cross-Encoder, Personalized PageRank를 각각 다른 위치에 붙여야 합니다. 결론부터 말하면 Cross-Encoder는 auto-seed 직전 정밀 rerank에, ColBERT는 후보 확장과 graph edge scoring에, PageRank는 query-personalized graph signal에 두는 편이 가장 자연스럽습니다.
이 글은 원본 HTML 초안을 Astro 블로그용 Markdown으로 옮기면서 Mermaid 그래프는 정적 SVG 이미지로 추출하고, 수식은 MathJax 없이도 깨지지 않도록 Unicode/텍스트 수식으로 정리한 버전입니다.
요약. Auto-seeding은 여전히 deterministic harness process로 두고, 모델들은 초기 working memory의 후보 품질을 높이는 보조 신호로만 쓰는 것이 안전합니다. 중요도 승격은 read/verify 이후 LLM policy가 담당해야 합니다.
내가 반도체 SOP, TSG, MyService case처럼 장비명·알람명·조치 문구가 중요한 검색 구조를 본다면, 이 확장은 “LLM에게 더 많이 맡기는 방식”이 아니라 “LLM이 판단하기 전에 상태를 더 잘 정리해주는 방식”에 가깝습니다.
1. ColBERT 먼저 이해하기
ColBERT는 dense embedding과 cross-encoder 사이의 중간 지점에 있는 검색 모델입니다. 일반 dense retriever는 문서 전체를 하나의 벡터로 압축합니다. 반면 cross-encoder는 query와 document를 함께 넣고 모든 토큰이 서로 attention할 수 있게 만들어 매우 정밀하지만, 후보 문서마다 모델을 한 번씩 돌려야 하므로 비용이 큽니다. ColBERT는 이 둘의 장점을 절충합니다.
메모. ColBERT의 핵심: query와 document를 각각 독립적으로 encode하되, 최종 점수 계산에서는 query token 하나하나가 document token 중 가장 잘 맞는 토큰을 찾도록 합니다. 이를 late interaction이라고 부릅니다.
1.1 검색 모델의 네 가지 계열
| 방식 | 대표 예시 | 작동 방식 | 장점 | 한계 |
|---|---|---|---|---|
| Lexical / Sparse | BM25, SPLADE | 단어, 토큰, 희소 가중치 기반 matching | 정확한 용어, 알람코드, 장비명에 강함 | 표현이 다르면 놓칠 수 있음 |
| Dense Bi-Encoder | DPR, E5, BGE류 | query와 doc을 각각 하나의 벡터로 encode | 빠르고 대규모 검색에 유리 | 세부 토큰 정보가 뭉개질 수 있음 |
| Late Interaction | ColBERT, ColBERTv2 | query/doc을 독립 encode하되 token-level matching 수행 | 세밀한 token matching과 검색 효율의 균형 | single-vector보다 index 용량과 계산량이 큼 |
| Cross-Encoder | BERT reranker, monoBERT류 | query와 doc을 함께 넣고 relevance score 산출 | 가장 정밀한 pairwise relevance 판단 | 후보마다 forward 필요, 대량 적용 어려움 |
1.2 ColBERT의 구조
ColBERT는 query와 document를 각각 BERT 계열 encoder에 통과시켜 토큰별 벡터를 만듭니다. 그런 뒤 각 query token vector가 document token vector들 중 가장 유사한 것을 찾고, 그 최대 유사도를 query token 전체에 대해 합산합니다.
그림 1. ColBERT는 query와 document를 따로 인코딩한 뒤 마지막 단계에서 토큰별 MaxSim을 계산한다.
점수는 개념적으로 다음과 같습니다.
수식 — ColBERT MaxSim
Score(q,d) = ∑ᵢ∈q maxⱼ∈d (Qᵢ · Dⱼ)
각 query token Qᵢ가 document token 중 가장 유사한 Dⱼ를 찾고, 그 유사도들을 합산합니다.
이 방식이 중요한 이유는 기술 문서에서 query의 각 토큰이 의미를 가질 때가 많기 때문입니다. 예를 들어 Recipe Body Unmatch Alarm이라는 질문에서 Recipe, Body, Unmatch, Alarm은 각각 중요한 단서입니다. 단일 dense vector로 전체를 압축하면 이런 세부 단서가 약해질 수 있지만, ColBERT는 query token별로 문서 안의 대응 토큰을 찾을 수 있습니다.
1.3 ColBERT가 dense보다 나은 지점
- 장점 1. 기술 용어 보존: 반도체 장비명, alarm phrase, sensor tag, parameter name처럼 단어 하나하나가 중요한 경우 ColBERT의 token-level matching이 유리합니다.
- 장점 2. offline indexing 가능: 문서 token vector는 미리 계산해서 index에 저장할 수 있습니다. query가 들어왔을 때는 query vector만 계산하고 late interaction으로 점수를 냅니다.
- 장점 3. cross-encoder보다 확장성 좋음: cross-encoder는 query-document pair마다 모델을 다시 돌려야 하지만, ColBERT는 문서 표현을 재사용할 수 있습니다.
- 장점 4. graph edge scoring에 적합: query-doc뿐 아니라 entity phrase-doc, alarm-doc, parameter-doc edge의 가중치를 계산하는 데 활용할 수 있습니다.
1.4 ColBERTv2가 해결한 문제
ColBERT의 약점은 문서마다 token vector를 여러 개 저장해야 한다는 점입니다. 단일 dense vector 방식보다 index 용량이 커집니다. ColBERTv2는 이 문제를 줄이기 위해 residual compression과 denoised supervision을 결합했습니다. 원 논문 기준으로 late interaction 모델의 공간 footprint를 6~10배 줄이는 방향을 제안합니다.
| 구분 | ColBERT | ColBERTv2 |
|---|---|---|
| 기본 구조 | query/doc 독립 encode + token-level late interaction | 동일한 late interaction 계열 |
| 주요 문제 | multi-vector index라 저장 공간이 큼 | residual compression으로 공간 부담 완화 |
| 학습 품질 | supervision에 민감 | denoised supervision으로 검색 품질 향상 |
| 실무 적용 | 품질 좋지만 index cost 고려 필요 | 대규모 corpus에 더 현실적 |
핵심. 반도체 RAG 관점: ColBERT는 “문서 전체 의미”보다 “질문 안의 세부 기술 토큰이 문서 어디에 잘 맞는가”를 보기에 좋습니다.
OES Intensity,EPD Channel,RF Reflected Power,Recipe Body Unmatch처럼 토큰 단위 fidelity가 중요한 도메인에 특히 잘 맞습니다.
2. Cross-Encoder와 ColBERT의 역할 차이
cross-encoder는 query와 document를 하나의 입력으로 넣습니다. 예를 들어 [CLS] query [SEP] document [SEP] 형태로 넣고, 모델이 query token과 document token 간의 full attention을 통해 relevance score를 냅니다. 그래서 정밀도는 높지만 후보 문서 수가 많으면 너무 비쌉니다.
그림 2. Cross-Encoder는 query와 document를 한 입력으로 묶어 가장 정밀한 relevance score를 낸다.
| 질문 | ColBERT | Cross-Encoder |
|---|---|---|
| 후보 10만 개를 직접 볼 수 있는가? | 상대적으로 가능. index 기반 검색 가능 | 거의 불가능. pair마다 forward 필요 |
| 후보 30~100개 정밀 rerank? | 가능하지만 최종 정밀 판단은 cross-encoder가 유리 | 가장 적합 |
| graph edge 후보를 많이 만들기? | 적합 | 너무 비쌈 |
| auto-seeding top-8 품질 올리기? | 중간 후보 정렬에 좋음 | 매우 적합 |
| 문서가 질문의 모든 조건을 만족하는지 판단? | 부분 matching에 강함 | 조건 결합 판단에 강함 |
설계 제안. ColBERT는 후보 확장, 중간 rerank, graph edge scoring에 쓰고, cross-encoder는 auto-seeding 직전 top 후보의 정밀 rerank에 쓰는 것이 가장 자연스럽습니다.
3. Harness-1의 원래 auto-seeding / evidence graph 구조
Harness-1에서는 LLM policy와 harness의 역할이 분리됩니다. LLM policy는 무엇을 검색하고, 어떤 문서를 curate하고, 무엇을 verify하고, 언제 end search할지 결정합니다. 반면 harness는 candidate pool, curated set, importance tag, evidence graph, verification cache, compression, deduplication, context budget rendering을 관리합니다.
3.1 원래 auto-seeding
Harness-1의 auto-seeding은 LLM 판단이 아닙니다. 첫 번째 성공한 search 또는 fan-out search 결과에서 reranker가 정렬한 top-8 문서를 harness가 자동으로 curated set에 넣고, importance는 모두 fair로 설정합니다.
첫 성공 검색
→ 검색 결과 후보 생성
→ reranker로 정렬
→ top-8 문서를 curated set에 자동 삽입
→ importance = fair
→ 이후 LLM policy가 promote / demote / remove / verify이 장치의 목적은 정답을 자동으로 판정하는 것이 아니라, 빈 curated set에서 시작하는 어려운 문제를 “초기 후보 set을 수정하는 문제”로 바꾸는 것입니다. 즉 construction from scratch를 refinement로 바꿉니다.
3.2 원래 evidence graph
Harness-1의 evidence graph도 LLM이 생성하지 않습니다. harness가 chunk가 candidate pool에 들어올 때마다 regex 기반 extractor로 다음 정보를 뽑습니다.
- multi-word capitalized proper nouns
- four-digit years 또는 decades
- numeric dates
그리고 다음 두 map을 유지합니다.
entity_to_docs: entity -> 이 entity가 등장한 문서 목록
doc_to_entities: doc -> 이 문서에 등장한 entity 목록이 graph는 엄밀한 knowledge graph라기보다 entity-document co-occurrence graph입니다. relation extraction을 하는 것이 아니라, “어떤 entity가 어떤 문서에 같이 등장했는가”를 보여줍니다.
주의. 한계: 원래 Harness-1의 evidence graph는 가볍고 빠르지만, 반도체 문서의 장비명, 알람코드, recipe, sensor tag, part name, cause/action/result 같은 도메인 entity를 충분히 잡기 어렵습니다. 그래서 사용자가 제안한 ColBERT, cross-encoder, PageRank 확장이 타당한 문제의식에서 출발합니다.
4. 사용자가 제안한 방법 요약
사용자의 제안은 세 가지로 나눌 수 있습니다.
- 제안 1 — Graph에 ColBERT 사용: evidence graph를 만들 때 단순 keyword/regex만 쓰지 말고, ColBERT로 query-doc, entity-doc, doc-doc relevance를 점수화하자는 제안입니다.
- 제안 2 — Auto-Seeding에 Cross-Encoder 사용: auto-seeding 문서가 이후 LLM policy의 초기 상태를 결정하므로, top-8을 만들 때 cross-encoder rerank를 쓰자는 제안입니다.
- 제안 3 — PageRank 개념 적용: 문서와 entity가 연결된 graph 위에서 중요한 문서를 계산하자는 제안입니다. 단, 전역 PageRank보다 query-personalized PageRank가 적합합니다.
4.1 결론부터 말하면
| 제안 | 타당성 | 권장 방식 |
|---|---|---|
| ColBERT를 graph에 사용 | 타당함. 다만 graph를 직접 생성한다기보다 edge weight를 계산하는 데 적합 | entity-doc, query-doc, doc-doc candidate edge scoring에 사용 |
| Auto-seeding에 cross-encoder 사용 | 매우 타당함. auto-seed top-8 품질이 중요하기 때문 | BM25/dense/ColBERT로 줄인 top 30~100 후보를 cross-encoder로 정밀 rerank |
| PageRank 적용 | 타당함. bridge document를 찾는 데 유리 | 전역 PageRank가 아니라 query entity와 초기 후보 문서를 seed로 하는 Personalized PageRank 사용 |
5. 추천 아키텍처
추천하는 전체 구조는 다음과 같습니다.
BM25 / Dense / SPLADE로 넓게 후보 검색
→ ColBERT로 후보와 graph edge를 풍부하게 점수화
→ Cross-Encoder로 auto-seeding 후보를 정밀 rerank
→ Domain Evidence Graph 위에서 Personalized PageRank
→ Score fusion + MMR diversity
→ Top-8을 fair로 auto-seed
→ LLM policy가 read / curate / verify / end_search
그림 3. 후보 검색, ColBERT, Cross-Encoder, evidence graph, PPR, MMR을 결합한 추천 흐름.
이 구조의 핵심은 auto-seeding은 여전히 LLM 판단이 아니라 harness의 deterministic process로 유지한다는 점입니다. 다만 원래 Harness-1의 단순 reranker top-8보다, cross-encoder와 graph signal을 결합해 더 좋은 초기 후보 set을 만듭니다.
6. Evidence Graph를 어떻게 자동 생성할 것인가
원래 Harness-1의 evidence graph는 regex 기반 entity-document co-occurrence graph입니다. 반도체 RAG에서는 이 graph를 그대로 쓰기보다 도메인 entity 기반 graph로 바꾸는 것이 좋습니다.
6.1 Node 설계
| Node 타입 | 예시 | 추출 방식 |
|---|---|---|
| Document / Chunk | SOP chunk, TSG chunk, MyService case | 문서 파서 / chunker |
| Equipment | INTEGER Plus, Supra-XP | 장비 사전 + regex |
| Module / Chamber | CHB-03, PM1, Transfer Module | 사전 + 패턴 |
| Alarm | Recipe Body Unmatch, Flow Switch Alarm | alarm 사전 + log 패턴 |
| Recipe | recipe name, step, body | recipe parser + exact matching |
| Parameter / Sensor Tag | OES intensity, EPD channel, RF reflected power | sensor tag dictionary + regex |
| Part | MFC, valve, gauge, pump | part ontology |
| Cause / Action / Result | 원인, 조치, 결과 | rule + LLM extractor 또는 작은 IE 모델 |
6.2 Edge 설계
| Edge | 의미 | 기본 weight 제안 |
|---|---|---|
doc contains equipment | 문서가 특정 장비를 언급 | 0.4 |
doc contains exact alarm | 문서가 알람명을 정확히 언급 | 1.0 |
doc mentions parameter | 문서가 관련 parameter/sensor를 언급 | 0.6 |
doc mentions action | 문서가 조치 방법을 포함 | 0.8 |
case resolved_by action | 이력에서 특정 조치가 문제를 해결 | 1.2 |
doc semantically_similar doc | 두 문서가 유사한 문제를 다룸 | ColBERT / dense로 계산 |
claim supported_by doc | verify 결과 특정 claim을 지지 | 1.2 이상 |
6.3 ColBERT는 graph를 “만드는” 도구가 아니라 edge를 “점수화”하는 도구
ColBERT가 자동으로 entity graph를 만들어주는 것은 아닙니다. graph의 node와 edge 후보는 extractor가 만듭니다. ColBERT는 그 후보 edge의 가중치를 더 잘 계산하는 데 사용합니다.
Entity Extractor:
doc_101 contains_alarm Recipe Body Unmatch
doc_101 contains_equipment INTEGER Plus
doc_101 contains_parameter Recipe Body
ColBERT Scorer:
score("Recipe Body Unmatch alarm", doc_101) = 0.91
score("INTEGER Plus recipe body", doc_101) = 0.82
score(doc_101, doc_205) = 0.76
Graph Updater:
edge weight를 ColBERT score와 exact match score로 보정
그림 4. Extractor가 node와 edge 후보를 만들고 ColBERT는 semantic edge weight를 보강한다.
6.4 자동 생성 pseudo-code
def process_chunk(chunk, query_entities):
doc_id = chunk.id
text = chunk.text
# 1. 중복 제거
if content_dedup.is_duplicate(text):
return
# 2. 후보 문서 저장
candidate_pool.add(doc_id)
full_text_store[doc_id] = text
# 3. 도메인 entity 추출
entities = domain_extractor.extract(text)
# equipment, alarm, recipe, parameter, part, cause, action, result
# 4. 기본 graph edge 생성
for e in entities:
graph.add_edge(doc_id, e.id, type=f"contains_{e.type}", base_weight=e.confidence)
# 5. ColBERT로 edge weight 보정
for e in entities:
semantic_score = colbert.score(e.surface_or_alias, text)
graph.update_weight(doc_id, e.id, combine(e.confidence, semantic_score))
# 6. query와 doc edge 추가
qd_score = colbert.score(query_text, text)
graph.add_edge("QUERY", doc_id, type="query_relevant_to_doc", weight=qd_score)
# 7. 필요 시 같은 alarm/equipment 후보군 내부 doc-doc edge 계산
for neighbor in get_local_candidate_docs(entities):
sim = colbert.doc_doc_score(doc_id, neighbor)
if sim > threshold:
graph.add_edge(doc_id, neighbor, type="semantic_neighbor", weight=sim)7. Cross-Encoder 기반 Auto-Seeding 설계
사용자의 제안 중 가장 바로 효과를 볼 가능성이 높은 것은 auto-seeding에 cross-encoder를 넣는 것입니다. 이유는 간단합니다. auto-seed된 문서는 이후 LLM policy가 계속 보는 초기 working memory가 됩니다. 첫 상태가 좋으면 policy가 읽고, 검증하고, 승격하는 과정이 훨씬 쉬워집니다.
7.1 기존 auto-seeding의 한계
원래 Harness-1에서는 첫 성공 검색의 reranked top-8을 fair로 넣습니다. 하지만 도메인 RAG에서는 다음 문제가 생길 수 있습니다.
- top-8이 같은 SOP의 near-duplicate chunk로 채워질 수 있음
- 장비명은 맞지만 알람이 다른 문서가 들어갈 수 있음
- 알람명은 맞지만 조치/원인 문서가 아니라 일반 설명 문서일 수 있음
- query의 복합 조건, 예를 들어 장비 + chamber + recipe + alarm을 모두 만족하지 못할 수 있음
7.2 개선된 auto-seeding 흐름
그림 5. ColBERT와 Cross-Encoder로 후보를 줄인 뒤 graph/PPR 신호와 다양성 제약을 합쳐 top-8을 고른다.
7.3 Cross-Encoder input 설계
cross-encoder에는 너무 긴 문서를 그대로 넣기 어렵습니다. 따라서 다음 중 하나를 입력으로 쓰는 것이 좋습니다.
| 입력 방식 | 설명 | 추천도 |
|---|---|---|
| title + snippet + top matching sentences | 검색 결과에서 query 관련 문장 4~8개만 넣음 | 초기 MVP에 가장 적합 |
| chunk 단위 scoring | 긴 문서를 여러 chunk로 나누고 max 또는 top-k average로 집계 | 문서가 길 때 필수 |
| structured field 포함 | 장비명, 알람명, 문서 타입, 발생 조건 등 metadata를 함께 넣음 | 도메인 RAG에서 강력 추천 |
7.4 Auto-seed는 여전히 fair로 넣는 것이 좋다
주의. Cross-encoder 점수가 높다고 해서 바로
high또는very high로 넣는 것은 조심해야 합니다. auto-seeding은 초기 후보를 넣는 단계이고, 최종 중요도 승격은 LLM policy의 read / verify 이후에 하는 것이 Harness-1의 설계 철학과 맞습니다.
Auto-seed:
top-8 documents -> curated_set
importance = fair
After LLM reads/verifies:
direct evidence -> high
verified decisive evidence -> very high
distractor -> low or remove7.5 Auto-seeding pseudo-code
def auto_seed(query, candidates, graph):
# 1. ColBERT로 후보 축소
colbert_ranked = colbert.rerank(query, candidates, top_k=150)
# 2. Cross-Encoder로 정밀 점수
ce_ranked = cross_encoder.rerank(query, colbert_ranked[:80], top_k=40)
# 3. Personalized PageRank 점수 계산
ppr_scores = personalized_pagerank(graph, seeds=get_query_seed_nodes(query))
# 4. score fusion
scored = []
for doc in ce_ranked:
score = (
0.40 * normalize(doc.cross_encoder_score)
+ 0.20 * normalize(doc.colbert_score)
+ 0.20 * normalize(ppr_scores.get(doc.id, 0.0))
+ 0.10 * exact_match_score(query.entities, doc)
+ 0.10 * domain_priority(doc)
)
scored.append((doc, score))
# 5. MMR + domain bucket diversity
selected = diversity_select(scored, k=8)
# 6. fair로 auto-seed
for doc in selected:
curated_set.add(doc.id)
importance[doc.id] = "fair"
return selected8. Personalized PageRank 적용 방식
사용자가 말한 “Google PageRank 개념”은 매우 좋은 직관입니다. 다만 그대로 전역 PageRank를 적용하면 문제가 생길 수 있습니다. 전역 PageRank는 전체 graph에서 많이 연결된 문서를 중요하게 봅니다. 반도체 문서에서는 공통 safety manual, 장비 개요서, 전체 alarm index 같은 허브 문서가 과대평가될 수 있습니다.
메모. 그래서 추천은 전역 PageRank가 아니라 Personalized PageRank입니다. 현재 query의 장비명, 알람명, recipe, parameter, 그리고 1차 검색 top 문서를 seed로 두고 random walk를 수행합니다.
8.1 Personalized PageRank 수식
수식 — Personalized PageRank
r = (1 − α)p + αAᵀr
p는 query-personalized seed vector입니다. 모든 노드를 균등하게 시작하지 않고 현재 질문과 관련된 entity/document에 teleport probability를 더 줍니다.
8.2 Seed vector 구성
| Seed 타입 | 예시 | 가중치 직관 |
|---|---|---|
| Query node | 원 질문 전체 | 기본 anchor |
| Exact alarm entity | Recipe Body Unmatch | 가장 높게 |
| Equipment entity | INTEGER Plus | 높게 |
| Recipe / parameter entity | Recipe Body, EPD Channel | 중간 |
| Initial retrieved docs | BM25/Dense/ColBERT top 문서 | 검색 신호 반영 |
8.3 Personalized PageRank가 잘 잡는 문서
PPR은 단일 relevance score만으로는 놓치기 쉬운 bridge document를 올려줄 수 있습니다.
그림 6. PPR은 query entity에서 직접 문서뿐 아니라 bridge document까지 점수를 전파한다.
위 예시에서 D4 Setup Manual은 query와 직접 단어 overlap이 낮을 수 있지만, alarm → parameter → setup procedure 경로로 연결될 수 있습니다. 이런 문서는 PPR이 보조 점수로 올려줄 수 있습니다.
9. 최종 scoring / MMR / 다양성 제약
9.1 FinalSeedScore
auto-seeding 후보는 하나의 점수만으로 고르기보다 여러 신호를 합치는 것이 좋습니다.
FinalSeedScore(d) =
α · CE(q,d)
+ β · ColBERT(q,d)
+ γ · PPR(d)
+ δ · ExactMatch(qₑ,d)
+ ε · DomainPriority(d)
− η · Redundancy(d)| 항 | 역할 | 초기 가중치 예시 |
|---|---|---|
CE(q,d) | cross-encoder query-doc 정밀 relevance | 0.40 |
ColBERT(q,d) | token-level semantic/lexical matching | 0.20 |
PPR(d) | graph 상 구조적 중요도 / bridge score | 0.20 |
ExactMatch(q_e,d) | 장비명, alarm code, recipe 등 정확 일치 | 0.10 |
DomainPriority(d) | TSG, resolved case, direct action 문서 우선 | 0.10 |
Redundancy(d) | 이미 선택된 문서와 중복이면 감점 | 별도 penalty |
9.2 MMR로 중복 방지
cross-encoder top-8을 그대로 auto-seed하면 비슷한 chunk가 몰릴 수 있습니다. 이를 막기 위해 MMR(Maximal Marginal Relevance)을 적용합니다.
수식 — MMR 선택 기준
d* = argmax_d [ λ·Score(d) − (1 − λ)·max_{s∈S} Sim(d,s) ]
이미 선택된 문서 S와 너무 유사한 문서는 감점합니다.
9.3 Domain bucket diversity
반도체 진단에서는 top-8을 단순히 점수순으로 고르는 것보다, 문서 타입을 나눠서 coverage를 확보하는 것이 좋습니다.
| Bucket | 권장 seed 수 | 예시 |
|---|---|---|
| 직접 TSG / Alarm 문서 | 2~3 | Recipe Body Unmatch 원인/조치 |
| 동일 장비 SOP | 1~2 | INTEGER Plus recipe 관리 절차 |
| 과거 해결 이력 | 1~2 | MyService case, Action/Result |
| 관련 parameter / sensor 설명 | 1 | Recipe Body, EPD, OES, RF 관련 설명 |
| Setup / Manual / Procedure | 1 | upload, sync, calibration procedure |
핵심. auto-seeding은 relevance만 최대화하면 안 됩니다. relevance + diversity + coverage를 함께 봐야 LLM policy가 이후 read/curate/verify를 잘할 수 있습니다.
10. 제안 구조의 타당성 평가
10.1 왜 타당한가?
- Harness-1의 약점을 직접 보완한다: 원래 evidence graph는 regex 기반이라 도메인 entity에 약합니다. ColBERT와 domain extractor를 붙이면 graph edge 품질을 높일 수 있습니다.
- Auto-seeding은 초기 상태이므로 정밀 rerank 가치가 크다: 초기 curated set이 좋으면 LLM policy가 덜 헤맵니다. cross-encoder는 top 후보의 조건 충족 여부를 정밀하게 판단하는 데 적합합니다.
- ColBERT는 반도체 기술 용어에 잘 맞는다: 장비명, recipe, alarm phrase, sensor tag처럼 세부 token matching이 중요한 도메인에서 single-vector dense보다 정보 손실이 적습니다.
- Personalized PageRank는 bridge 문서를 찾는 데 유리하다: 직접 검색 점수는 낮지만 여러 단서를 연결하는 문서를 올려줄 수 있습니다. multi-hop 진단에서 유용합니다.
- LLM policy의 부담을 줄인다: LLM에게 “처음부터 중요 문서를 골라라”가 아니라 “정리된 후보와 graph를 보고 판단하라”로 바꿉니다. Harness-1 철학과 맞습니다.
- Ablation 가능성이 좋다: cross-encoder auto-seed, ColBERT edge, PPR을 각각 켜고 끄며 seed recall, curated recall, answer recall을 비교할 수 있습니다.
10.2 원래 Harness-1과의 정합성
| Harness-1 원칙 | 사용자 제안과의 관계 |
|---|---|
| LLM policy는 의미적 의사결정만 한다 | auto-seeding, graph 생성, score fusion은 harness가 담당하므로 원칙과 일치 |
| harness는 recoverable bookkeeping을 관리한다 | ColBERT/PPR/cross-encoder score도 working memory를 구성하는 derived state로 볼 수 있음 |
| auto-seeding은 warm-started curation이다 | cross-encoder를 넣으면 warm-start의 품질이 좋아짐 |
| evidence graph는 compact derived-state rendering이다 | 도메인 graph + PPR은 derived state를 더 지능적으로 만드는 확장 |
| importance tag는 policy가 수정한다 | auto-seed는 여전히 fair로 시작하고, high/very high는 read/verify 이후 policy가 결정 |
10.3 가장 타당한 적용 순서
- Cross-encoder auto-seeding: 가장 빠르게 성능 개선을 확인할 수 있습니다.
- Domain entity evidence graph: graph의 node/edge 품질을 먼저 올려야 PageRank가 의미 있어집니다.
- ColBERT edge scoring: query-doc, entity-doc, doc-doc edge의 semantic weight를 보강합니다.
- Personalized PageRank: graph가 어느 정도 신뢰 가능해진 뒤 구조적 중요도를 반영합니다.
- Learning-to-rank: 로그가 쌓이면 heuristic score fusion을 학습 기반으로 바꿉니다.
11. 리스크와 완화책
| 리스크 | 왜 문제인가 | 완화책 |
|---|---|---|
| Cross-encoder 비용 증가 | 후보마다 pairwise scoring 필요 | top 30~100 후보에만 적용, batch inference, distilled reranker 사용 |
| Auto-seed top-8의 다양성 부족 | 같은 문서군만 들어가면 LLM이 다른 원인/조치를 놓침 | MMR + bucket diversity + document-level aggregation |
| Graph edge noise | 잘못된 edge는 PPR을 망가뜨림 | edge type별 weight, exact alarm 우선, low-confidence edge 제한 |
| 허브 문서 과대평가 | 장비 개요서, 공통 safety 문서가 너무 높게 랭크될 수 있음 | 전역 PageRank 금지, Personalized PageRank 사용, generic doc penalty |
| 도메인 entity extractor 오류 | 장비명/알람명 추출 실패 시 graph 품질 저하 | 사전 기반 + regex + weak supervision + human feedback loop |
| ColBERT index 용량 | multi-vector index라 저장공간이 큼 | ColBERTv2, quantization, shard, hot corpus 우선 적용 |
| 표/이미지/PDF 문서의 정보 손실 | cross-encoder나 ColBERT가 텍스트화된 chunk만 봄 | 표 구조 파서, 이미지 캡션, OCR 신뢰도 metadata, table-aware chunking |
| LLM policy와 reranker score 충돌 | reranker가 높게 본 문서를 LLM이 distractor로 볼 수 있음 | auto-seed는 fair로만 넣고, final promotion은 read/verify 후 policy가 담당 |
12. 구현 로드맵과 평가 지표
12.1 MVP 1: Cross-Encoder Auto-Seeding
가장 먼저 구현할 것을 추천합니다. 기존 검색 결과 top-N을 cross-encoder로 rerank한 뒤 top-8을 fair로 auto-seed합니다.
- 기존 BM25/dense/SPLADE 검색 결과 100개 수집
- cross-encoder rerank
- near-duplicate 제거
- MMR 적용
- top-8 fair auto-seed
- 기존 auto-seed와 seed recall@8 비교
12.2 MVP 2: Domain Evidence Graph
그 다음은 graph node/edge 품질을 올리는 단계입니다.
- 장비명 사전 구축
- alarm code/message 사전 구축
- recipe / parameter / sensor tag extractor 구축
- cause/action/result 패턴 추출
- doc-entity graph 저장
- working memory에 frequent entity / bridge doc / singleton rendering
12.3 MVP 3: ColBERT Edge Scoring
도메인 graph가 만들어진 뒤 ColBERT로 edge weight를 보강합니다.
- query-doc ColBERT score 저장
- entity phrase-doc ColBERT score 저장
- 같은 장비/알람 후보군 내부 doc-doc similarity 계산
- edge weight normalization
- PPR에 반영
12.4 MVP 4: Personalized PageRank
Graph가 충분히 안정되면 PPR을 붙입니다.
- query entity를 seed vector로 변환
- initial retrieval top docs를 seed에 일부 반영
- edge type별 weight 적용
- PPR score를 FinalSeedScore에 0.1~0.2 정도로 반영
- hub 문서 penalty 적용
12.5 평가 지표
| 평가 지표 | 의미 | 왜 중요한가 |
|---|---|---|
| Seed Recall@8 | auto-seed top-8에 gold/relevant 문서가 들어가는 비율 | 초기 상태 품질 확인 |
| Seed Diversity | top-8이 문서 타입/원인/조치/이력 측면에서 다양한가 | 중복 top-8 방지 |
| Curated Recall | 최종 curated set에 relevant 문서가 포함되는가 | Harness-1 핵심 지표 |
| Final-Answer Recall | 정답 근거 문서가 최종 set에 들어가는가 | 답변 가능성의 직접 지표 |
| Trajectory Recall | 검색 과정 중 relevant 문서를 본 적이 있는가 | discovery와 selection 문제 분리 |
| Time / Cost per Query | cross-encoder/ColBERT/PPR 추가 비용 | 실무 적용 가능성 |
| Action Mix | search/read/curate/verify 비율 | search-only collapse 여부 확인 |
12.6 Ablation 계획
Baseline: 기존 Harness-style auto-seed
+ CrossEncoder auto-seed
+ Domain evidence graph
+ ColBERT edge scoring
+ Personalized PageRank
+ MMR diversity
각 단계마다:
- seed recall@8
- curated recall
- final-answer recall
- latency
- cost
- action mix
을 비교한다.13. 최종 정리
핵심.
1. ColBERT는 graph 생성기가 아니라 graph를 더 잘 점수화하는 도구입니다.
Entity extractor가 node/edge 후보를 만들고, ColBERT는 query-doc, entity-doc, doc-doc edge의 semantic weight를 계산하는 데 쓰는 것이 적합합니다.
핵심.
2. Cross-encoder는 auto-seeding에 매우 적합합니다.
Auto-seed top-8은 LLM policy가 처음 보는 작업 상태입니다. 여기에 좋은 후보를 넣는 것은 이후 read/curate/verify 품질에 큰 영향을 줍니다.
핵심.
3. PageRank는 Personalized PageRank로 써야 합니다.
전역 PageRank는 허브 문서를 과대평가할 수 있습니다. 현재 query의 장비, 알람, recipe, parameter, 초기 후보 문서를 seed로 둔 PPR이 더 맞습니다.
핵심.
4. Auto-seeding은 high가 아니라 fair로 시작하는 것이 좋습니다.
Cross-encoder가 높게 평가했더라도, 최종 중요도 승격은 LLM policy가 read/verify 이후 수행해야 합니다. 이것이 Harness-1의 state editing 철학과 맞습니다.
최종 추천 구조:
BM25 / Dense / SPLADE
→ ColBERT candidate + edge scoring
→ Cross-Encoder auto-seed rerank
→ Domain Evidence Graph
→ Personalized PageRank
→ Score Fusion + MMR
→ Top-8 fair auto-seed
→ LLM Policy가 read / curate / verify / end_search이 구조는 “프롬프트만으로 20B 모델이 문서 중요도를 잘 판단한다”는 접근이 아닙니다. 오히려 Harness-1의 핵심 철학인 stateful cognitive offloading을 더 강화합니다. 즉, LLM policy는 의미적 판단을 하고, harness는 검색 상태·후보 품질·graph 구조·초기 seed를 더 신뢰성 있게 만들어주는 방향입니다.
자주 묻는 질문
Q1. ColBERT로 evidence graph를 자동 생성하면 되나요?
아닙니다. ColBERT는 node와 edge를 직접 만들어주는 graph generator가 아니라, extractor가 만든 후보 edge의 semantic weight를 보강하는 scorer로 쓰는 편이 안전합니다.
Q2. Auto-seeding에는 ColBERT와 Cross-Encoder 중 무엇이 더 직접적인가요?
초기 top-8 품질을 바로 올리는 목적이라면 Cross-Encoder가 더 직접적입니다. 다만 비용 때문에 BM25, dense, SPLADE, ColBERT로 후보를 30~100개 수준까지 줄인 뒤 적용하는 구조가 현실적입니다.
Q3. PageRank는 전역으로 한 번 계산해두면 충분한가요?
반도체 문서 검색에서는 전역 PageRank보다 Personalized PageRank가 적합합니다. 전역 점수는 공통 매뉴얼이나 안전 문서 같은 허브를 과대평가할 수 있기 때문입니다.
Q4. Cross-Encoder 점수가 높으면 auto-seed importance를 high로 넣어도 되나요?
권장하지 않습니다. auto-seeding은 초기 후보를 넣는 단계이므로 fair로 시작하고, LLM policy가 read와 verify를 거친 뒤 high 또는 very high로 승격하는 흐름이 Harness-1의 설계 철학과 맞습니다.
관련 글
- ColBERT Late Interaction은 일반 dense retrieval과 뭐가 다를까?
- Retrieval 성능의 한계에 부딪쳤을 때: SPLADE 전 단계 추적
- 하네스 엔지니어링 검증 루프: Hooks와 반복 설계
참고 문헌 및 근거
- Harness-1: Reinforcement Learning for Search Agents with State-Externalizing Harnesses. 업로드된 논문 PDF 기준.
- Omar Khattab, Matei Zaharia. ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT. SIGIR 2020 / arXiv:2004.12832.
- Keshav Santhanam, Omar Khattab, Jon Saad-Falcon, Christopher Potts, Matei Zaharia. ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction. NAACL 2022 / arXiv:2112.01488.
- Rodrigo Nogueira, Kyunghyun Cho. Passage Re-ranking with BERT. arXiv:1901.04085.
- Lawrence Page, Sergey Brin, Rajeev Motwani, Terry Winograd. The PageRank Citation Ranking: Bringing Order to the Web. Stanford technical report, 1998.
이 글은 기술 블로그 초안으로 작성된 HTML을 ruahverce Astro 블로그 형식에 맞춰 이관한 글입니다. 실제 구현에서는 corpus 규모, latency budget, reranker 비용, 사내 문서 타입, gold label 유무에 맞게 score weight와 bucket policy를 튜닝해야 합니다.