Tag: Prompt_Engineering
All the articles with the tag "Prompt_Engineering".
-
LLM 프롬프트 규칙을 두 번 고쳤는데, 정작 노트를 나누지 말았어야 했다
LLM이 만든 형제 노트가 링크만 남기고 텅 비는 버그를 프롬프트 규칙으로 두 번 고쳤다. 원문을 다시 보니 두 강좌의 설명이 같았고, 노트를 나누지 말고 합쳐야 했다.
-
임베딩 필터를 걷어내니, 중복이 오히려 더 많이 잡혔다
LLM이 만든 형제 노트의 중복을 잡던 임베딩 후보 필터를 걷어내고 노트 전체를 한 번에 LLM에 맡겼다. 허브 노트 예외 조항 하나로 정밀도가 55%에서 100%가 됐고, 깨끗하다던 묶음에서도 중복이 나왔다.
-
검증은 다른 쌍으로 했는데, 원래 그 사례는 다시 안 봤다
Obsidian 플러그인의 LLM 병합 판단 프롬프트에서 오탐을 고치고 GitHub 이슈까지 닫았는데, 정작 오탐을 일으켰던 원래 사례는 그 사이 한 번도 다시 테스트하지 않았다. 며칠 뒤 실제 vault 전체 조건으로 돌려보니 판단이 뒤집혔고, 실제로 병합해보니 원래 판단 자체가 틀렸을 가능성이 높았던 기록.
-
리스트 밀도 상위 4개 중, 서브에이전트가 2개를 놓쳤다
Claude Code 서브에이전트에게 맡긴 전수 감사가 56개 파일 중 2개를 CLEAN으로 잘못 보고했다. 불릿 리스트가 많은 파일에서 '다 읽었다'는 판정이 항목별 대조가 아니라 뭉뚱그린 훑어보기였다는 걸 프롬프트 A/B 테스트로 확인하고, 체크리스트를 강제하는 프롬프트로 고친 기록.
-
정답은 이미 있었고, 안 쓴 쪽이 문제였다
위키링크가 전체 경로 없이 베어(bare) 제목으로 남는 버그를 고치려고 사후 복구 방식을 두 번 제안했다가 두 번 다 정정당했다. 마지막 정정은 질문 하나였다 — 링크를 만들 때 이미 정답 정보를 받았을 텐데, 그걸 안 쓰는 쪽이 문제 아니냐는 것.
-
경로는 고쳤는데, 화면엔 옛 이름이 남아 있었다
/refactor 제안 카드가 읽기 어렵다는 스크린샷을 받고 4가지를 한 번에 고쳤다. 그런데 그 UI로 실제 분할을 실행해보니, 완전히 다른 층위의 버그가 드러났다 — 링크의 경로는 새 타겟으로 정확히 재지정됐는데, 화면에 보이는 이름은 삭제된 옛 노트 제목 그대로였다.
-
몇 주 뒤, 그 감사 장치가 못 보는 경우를 찾았다
예전에 32번 중 32번을 다 맞혔던 병합 감사 장치가, 실전에서 상위 개념 노트와 그 하위 유형 노트를 동일 대상으로 오판했다. 원인은 판단력이 아니라 설계 자체 — 그 감사는 처음부터 이 종류의 오판을 잡도록 만들어진 게 아니었다.
-
확신을 실측 앞에 세워봤다 9편 — 답은 두 문서 안이 아니라, 밖에 있었다
Obsidian 플러그인 `/refactor`에서 병합(merge) 시점에 개입하는 것도, 판단을 생성 대신 검증으로 바꾸는 것도 안 됐다. 본문 전체를 줘도 모델은 계속 확신에 차서 틀렸다. 문제는 판단력 부족이 아니라 근거 부족 — 그 판단에 필요한 증거가 애초에 그 두 문서 안에 없었다는 것이었다.
-
확신을 실측 앞에 세워봤다 8편 — 격리할수록 좋아진다는 것도 절반만 맞았다
Obsidian 플러그인 `/refactor`에서, 노트 하나만 있는 카탈로그에서는 92% 성공, 오탐은 0건이었다. 그대로 실전 규모(노트 145개)에 넣었더니 25%로 주저앉았다. reasoning effort(추론 강도)를 올리면 나아질 줄 알았는데, 시도하는 족족 더 나빠졌다.
-
고치라는 지시부터, 다시 봐야 했다 4편 — 지우라는 지시와, 어떻게 지울지는 다른 질문이었다
실제 vault에서 임베딩용 API 키(`embeddingApiKey`)가 계속 비어 있는 걸 발견하고 추적해보니, 설계 문서에 열려 있던 질문이 사용자 확인 없이 조용히 결정돼 있었다. 그런데 그걸 고치라는 지시를 받고 나도 똑같은 실수를 반복할 뻔했다.