MLH 글로벌 해커 주간(Global Hack Week)의 빌더스 위크(Builders Week) Day 5. 이번 주 내내 Build Buddy는 AI 모델들로부터 C# 컴파일러 오류에 대한 설명을 수집해 왔습니다. 그중 일부는 맞고, 일부는 자신만만하게 틀렸습니다. 오늘 저는 이 설명들을 벡터 데이터베이스에 넣어 RAG 시스템처럼 검색했을 때 어떤 일이 발생하는지 확인했습니다.
설정 방법 (The setup)
- 이번 주 동안 Gemma 3 4B와 Grok 4.7으로부터 수집한 컴파일러 오류에 대한 실제 설명 12개
- 각 항목은 수동으로 검토: 정확함, 틀림, 또는 일관성이 없음
- Ollama를 통해
nomic-embed-text로 **로컬 임베딩(Embedded locally)**하여 텍스트가 노트북을 벗어나지 않도록 함
VECTOR(768) 컬럼과 HNSW 인덱스를 가진 Tiger Data 하이퍼테이블에 저장
CREATE TABLE fix_notes (
noted_at TIMESTAMPTZ NOT NULL,
model TEXT NOT NULL,
...
그 후 저는 일반 영어로 질문을 던지고 코사인 거리(cosine distance)를 기준으로 모든 설명을 순위화했습니다 (거리가 낮을수록 의미적으로 더 가깝다는 뜻).
잘 작동할 때는 매우 잘 작동한다 (When it works, it works well)
"비동기 호출은 Task를 반환하며 await 없이 문자열에 할당되었다."
가장 높은 일치 항목은 Grok의 설명이었습니다: "GetStringAsync는 Task<string>을 반환하므로 해당 호출은 await되어야 합니다." 거리는 0.245였습니다. 다음으로 좋은 것은 0.338이었습니다.
심지어 동일한 코드를 가진 두 오류를 구별해냈습니다. Gemma는 CS0029에 대해서도 설명했지만, 그것은 문자열을 int에 할당하는 것에 관한 것이었습니다. 이 항목은 7위에 올랐습니다. 오직 오류 코드만으로 일치시킨다면 둘 다 같은 것으로 간주했을 것입니다.
최고 일치 항목이 틀렸다 (The best match was wrong)
"문장 끝에 세미콜론(semicolon)이 누락되었습니다."
| # | Model | Code | Review | Distance |
|---|
| 1 | gemma3:4b | CS1002 | 틀림 | 0.231 |
| ... | | | | |
가장 가까운 일치 항목은 명확한 차이로, 세미콜론이 "필요하지 않았다"고 설명하는 Gemma의 내용이었습니다. 이는 실제 오류와 정반대되는 내용입니다.
벡터 검색은 정확히 올바른 *주제(topic)*를 찾아냈습니다. 하지만 그 내용이 진실인지는 전혀 알지 못합니다. RAG 시스템이라면 이 내용을 검색하여 자신감 있게 반복했을 것입니다.
두 개의 필터, 두 가지 다른 역할
필터 1: 신뢰할 수 있는 출처만 사용하기(trusted sources only). WHERE review = 'correct'를 추가하여 잘못된 답변을 제거했습니다. 하지만 제 데이터에는 정확한 세미콜론 설명이 없었기 때문에, 검색은 대신 가장 가까운 잔여물들(leftovers)을 반환했습니다. 이는 누락된 리턴 값에 대한 노트였으며, 0.318 이상에서 나타났습니다. 여전히 답변이지만, 관련 없는 내용입니다.
필터 2: 거리 임계값(distance threshold). 제 데이터의 모든 실제 일치 항목은 0.186과 0.261 사이에 점수를 받았습니다. 관련 없는 모든 내용은 0.318 이상에서 점수를 받았습니다. 따라서 약 0.30 정도의 임계값을 설정하면 "관련 내용 없음(nothing relevant found)"을 포착할 수 있습니다.
하지만 이 임계값만으로는 충분하지 않습니다. 잘못된 세미콜론 답변은 0.231점을 받아, 편안하게 그 범위 안에 있었습니다.
따라서 검색에는 다음 두 가지가 모두 필요합니다:
- 신뢰할 수 있는 출처(Trusted sources): 잘못된 답변이 검색되는 것을 방지하기 위함입니다.
- 관련성 임계값(Relevance threshold): 관련 없는 답변이 사용되는 것을 막기 위함입니다.
- 그리고 두 가지 모두 통과하는 것이 없을 때: "신뢰할 수 있는 답변을 가지고 있지 않습니다."
시간 필터링도 같은 방식으로 작동했습니다. WHERE noted_at >= '2026-11-09'를 사용하자 Grok의 11월 8일 async 설명이 제거되었고, 남아있는 결과들은 모두 미약했습니다.
한계점(Limits)
설명 12개, 질문 5개, 임베딩 모델 1개, 그리고 제가 검토한 내용입니다. 0.30 임계값은 이 데이터에만 적합합니다. 이것은 벤치마크가 아닌 시연입니다.
전체 순위, 데이터 및 스크립트: db/fix-notes-results.md
다음 계획(Next)
Builders Week은 목요일에 끝납니다. 그 이후에는 issue #1: 동작 검사(behaviour checks)가 진행될 것이므로, 수정 사항이 적용되려면 그리고 동일하게 작동해야 합니다. 오늘 배운 교훈은 여기에도 적용됩니다: AI의 답변이 보기에 올바롭다고 해서 실제로 그렇다는 의미는 아닙니다.
작성 과정: 스키마(schema), 임베딩 스크립트, 분석은 Claude와 함께 진행했으며; 저는 모든 것을 제 노트북과 Tiger Data 콘솔에서 실행했고, 모든 숫자는 해당 실행 결과에서 나온 것입니다.