LLM WIKI V6 - 피드백 반영 기능

About this offer

LLM Wiki v6 — 답변·피드백·사람의 평가를 저장한다 잘못된 답변을 나중에 검토할 수 있도록, 당시의 근거와 사용자의 지적, 사람이 확인한 결과를 남긴다. v4까지 Wiki 구축·질의응답·원본 변경에 따른 갱신을 구현했고, v5에서는 성능과 안정성의 개선 방향을 정리했다. v6에서는 답변마다 기록을 남기고, 별도 호출로 사용자 피드백과 사람의 평가를 저장하는 기능을 추가했다. 이 글의 중심 범위는 evaluations 테이블에 사람이 작성한 평가를 저장하는 단계까지다. 평가를 바탕으로 Wiki를 갱신할지, 탐색·답변 정책을 바꿀지 결정하고 적용하는 연결은 이후 작업이다. 사용자가 질문 ↓ 서버: answer_id 발급 → 답변 생성 → answers에 기록 저장 → 답변 반환 ↓ 개발자·클라이언트·에이전트: 피드백 API 또는 MCP 도구 호출 ↓ 서버: feedback에 사용자 피드백 저장 ↓ 사람: 접수된 피드백을 검토하며 당시 답변·원문을 대조 ↓ 개발자·검토자: 평가 API 또는 스크립트로 검토 결과 제출 ↓ 서버: evaluations에 평가 저장 피드백 저장과 평가 저장은 각각 별도 호출이다. 피드백이 들어온 뒤 원인을 분석하고 평가를 작성하는 과정은 사람이 수행한다. 1. 질문에 답할 때 당시의 근거도 함께 저장한다 다음은 동작을 설명하기 위한 가상 사례다. 실제 비교 실험의 결과나 현재 저장소의 최신 배포 정책을 뜻하지 않는다. 현재 원문에는 배포 승인자가 팀 리드와 SRE 온콜 이라고 적혀 있다. 과거 원문에는 팀 리드 만 적혀 있다. 시스템이 과거 문서를 참고해 잘못 답했다고 가정한다. 사용자: “지금 배포하려면 누구 승인이 필요해?” 시스템: “팀 리드의 승인이 필요합니다.” POST /answer 는 요청을 받으면 answer_id 를 발급한다. 답변을 생성한 뒤 질문·답변·출처·실행 기록을 answers 테이블에 저장하고, 그다음 사용자에게 답변과 ID를 반환한다. 설명을 위해 이 답변의 ID를 A001 이라고 부르겠다. 실제 API에서는 발급받은 UUID를 사용한다. answers에 저장된 A001의 내용 — 설명을 위해 요약한 형태 질문: 지금 배포하려면 누구 승인이 필요해? 답변: 팀 리드의 승인이 필요합니다. 참고한 근거: 과거 배포 가이드의 “승인자: 팀 리드” 실행 기록: 검색 결과 또는 읽은 Wiki 경로, 모델 호출, 시간·토큰 등 아직 사용자가 오류를 지적하지 않았어도 기록을 저장한다. 나중에 같은 질문을 다시 실행하면 다른 문서를 찾거나 다른 답을 만들 수 있으므로, 사용자가 실제로 받은 답변과 당시의 근거 를 보존해야 하기 때문이다. 기본 저장소는 .local/evaluation.sqlite3 이다. 기록에는 요청으로 받은 대화 이력, 응답 상태, 코드 해시, Wiki 구축 지문 또는 검색 문서의 색인 해시도 포함된다. 저장된 답변을 다음 대화의 근거로 자동 주입하지는 않는다. 구현: 답변 API 의 answer() , 기록 저장소 의 AnswerStore.save() . 2. 사용자의 지적은 별도 호출로 feedback에 저장한다 사용자가 답변을 보고 문제를 발견한다. 사용자: “틀렸어. SRE 온콜 승인도 필요한데 빠졌잖아.” 이 말 자체가 자동으로 DB에 저장되는 것은 아니다. 개발자나 클라이언트가 피드백 API를 호출하거나, 대화 중인 에이전트가 submit_answer_feedback MCP 도구를 호출해야 한다. 별도 피드백 화면은 구현 범위에 포함하지 않았다. 예를 들어 개발자가 A001의 실제 ID로 POST /answers/{answer_id}/feedback 을 호출한다. { "rating": "unhelpful", "category": "answer", "comment": "SRE 온콜 승인도 필요한데 답변에서 빠졌어요." } 서버는 이 내용을 feedback 테이블에 저장하고 A001에 연결한다. 이때 category 도 호출자가 입력한 분류다. 서버가 원인을 분석해 붙인 결과가 아니다. unhelpful 에는 이유를 담은 코멘트가 필요하다. A001의 답변 기록 └─ 사용자 피드백: “SRE 온콜 승인이 빠졌어요.” 여기까지는 사용자의 지적을 접수한 상태다. 원문을 확인해 답변이 틀렸다고 판정하거나, 원인을 분석하거나, Wiki를 수정하는 작업은 실행하지 않는다. 구현: 기록 저장소 의 AnswerStore.add_feedback() , MCP 도구 의 submit_answer_feedback() . 3. 사람이 접수된 피드백을 검토한다 검토의 출발점은 사용자가 남긴 피드백이다. 이 사례에서 개발자나 검토자가 확인할 항목은 “SRE 온콜 승인이 빠졌어요”라는 지적이 맞는지, 맞다면 왜 누락됐는지 다. 피드백 내용만으로는 이를 판단할 수 없으므로, 연결된 답변 ID인 A001로 당시 기록을 조회한다. GET /answers/{answer_id} 또는 get_answer_record MCP 도구를 호출하면 당시 요청·답변·실행 기록과 연결된 피드백·평가를 함께 확인할 수 있다. 현재 API·MCP의 조회 기능은 답변 ID 단위이며, 미검토 피드백 목록을 모아 보여주는 기능은 별도로 구현하지 않았다. 이 사례에서 검토자는 다음 내용을 대조한다. 확인 대상 사례에서 확인한 내용 사용자 질문 현재 배포 승인자를 물었다. 실제 답변 팀 리드만 안내했다. 당시 사용한 근거 과거 가이드의 “승인자: 팀 리드”를 사용했다. 현재 원문 팀 리드와 SRE 온콜의 승인이 필요하다. 이를 보고 검토자는 “현재 규칙을 묻는 질문에 과거 규칙을 근거로 답했다”고 판단한다. 만약 당시 읽은 문서에 두 승인자가 모두 적혀 있었다면, 답변 생성 중 누락했는지 살펴봐야 한다. 즉, 검토 대상은 접수된 피드백이고, 답변 기록과 원문은 그 지적을 확인하고 원인을 조사하는 자료 다. 현재 구현에는 피드백을 입력받아 원인을 자동 분석하는 함수가 없다. 평가 API 자체는 피드백이 없어도 사용할 수 있지만, 여기서는 접수된 피드백을 계기로 검토하는 흐름을 설명한다. 4. 검토 결과를 별도 호출로 evaluations에 저장한다 검토자는 판단한 내용을 작성해 POST /answers/{answer_id}/evaluation 으로 제출한다. A001에 대한 입력 예시는 다음과 같다. { "reviewer": "reviewer-1", "verdict": "incorrect", "evidence": "mixed", "reason": "현재 승인자를 물었지만 과거 가이드를 근거로 답했다. 팀 리드는 맞으나 현재 필요한 SRE 온콜 승인이 누락됐다.", "expected": "팀 리드와 SRE 온콜의 승인이 필요하다고 현재 원문을 근거로 답한다.", "expected_status": "answered" } 서버는 입력 형식을 확인하고 evaluations 테이블에 저장한다. verdict 는 정오 판정, evidence 는 근거 평가, reason 은 검토 이유, expected 는 기대 답이다. 모두 검토자가 작성한 값이다. 같은 작업은 사람이 작성한 평가 JSON 파일을 scripts/review_answers.py 에 전달해 수행할 수도 있다. 실행 방법은 README의 v6 안내 에 정리했다. 저장 후 A001을 조회하면 다음 세 종류의 기록을 함께 볼 수 있다. A001 answers: “팀 리드의 승인이 필요합니다.” + 당시 요청·근거·실행 기록 feedback: “SRE 온콜 승인이 빠졌어요.” evaluations: 사람이 확인한 판정·이유·기대 답 기존 답변과 피드백은 그대로 보존한다. 평가를 다시 제출하면 이전 평가를 덮어쓰지 않고 추가하며, 비교·사례 내보내기에는 최신 평가를 사용한다. 구현: 기록 저장소 의 EvaluationInput 과 AnswerStore.evaluate() . evaluate() 는 입력받은 평가를 저장하는 함수이며, 스스로 정답이나 원인을 판단하지 않는다. 5. 저장된 평가를 Wiki 갱신에 연결하는 것은 이후 작업이다 A001에 위 평가를 저장해도 Wiki 내용과 답변 정책은 바뀌지 않는다. 현재 Wiki 갱신기는 sources/ 의 원본 변경을 감지하며, evaluations 테이블을 읽어 갱신하지 않는다. 예를 들어 이 사례를 실제로 개선하려면 사람이 원인에 따라 다음 작업을 선택해야 한다. 발견한 문제의 예 이후에 선택할 작업 원본에 SRE 온콜 승인 규칙 자체가 빠져 있다. 확인된 정책에 맞게 원본을 보완하고 Wiki 갱신을 실행한다. 원본은 맞지만 생성된 Wiki에서 SRE 온콜을 누락했다. Wiki 생성 로직·프롬프트 등을 검토하고 재생성한다. Wiki는 맞지만 과거 페이지를 선택하거나 답변에서 조건을 누락했다. 탐색·답변 로직이나 정책을 수정한다. 평가에서 수정 대상을 결정하고, 변경을 적용하는 연결은 아직 구현하지 않았다. v6에서는 그 결정을 내릴 때 참고할 답변·피드백·검토 결과를 보존한다. 재검증을 위한 보조 도구는 마련돼 있다. 예를 들어 A001처럼 사람의 평가가 있는 기록은 “배포 승인자가 누구인가?”라는 질문과 기대 답을 평가 사례로 내보낼 수 있다. 개발자가 수정 작업을 마친 뒤 비교 도구를 별도로 실행하면 같은 질문의 새 답변을 기록할 수 있다. 보조 도구 현재 가능한 작업 review_answers.py 사람이 작성한 평가 저장, 검토된 사례 내보내기, 보고서에 평가 반영 compare_answers.py 같은 조건에서 기존 검색과 Wiki의 답변·실행 기록 수집 compare_wiki_updates.py 같은 원본 변경에 대한 전체 재구축과 부분 갱신 비교 이 도구들도 별도 실행이 필요하다. 기대 답은 평가에 사용하며, Wiki 생성이나 답변 모델의 입력에 넣지 않는다. 새 답변의 의미적 정확성은 사람이 검토한다. 검증 범위 자동 테스트에서는 모델 대역으로 다음 동작을 확인하도록 구성했다. 테스트 시나리오 확인할 동작 답변을 저장하고 API를 다시 생성한 뒤 조회한다. 당시 요청·답변 기록을 다시 읽을 수 있다. 피드백과 사람의 평가를 각각 제출한다. 같은 답변 ID에 연결되고 기존 답변은 보존된다. 여러 질문을 동시에 처리한다. 요청별 ID와 기록이 섞이지 않는다. 모델 호출이 실패한다. 실패 기록을 저장하고 답변 ID로 조회할 수 있다. 피드백만 있는 사례를 평가 질문으로 내보내려 한다. 사람의 평가가 없으면 거절한다. 관련 테스트는 답변 기록 테스트 와 비교 실행 테스트 에 있다. 기존 구현 검증 기록은 전체 테스트 201개 통과·DB 연동 테스트 18개 건너뜀 이며, 실제 모델을 반복 호출한 품질·시간·비용 비교와 사람의 의미 평가는 아직 수행하지 않았다. 위 승인자 사례 역시 동작 설명을 위한 가상 시나리오다.