AI 기억이 일하게 하기
적어 두는 것과 그것이 행동에 실리는 것은 다르다
조직 위키와 AI 기억의 셋째 갈래입니다. AI에게 지시문과 메모리를 쥐여 주고도 그것이 일하지 않았던 자리를 모았습니다.
요지
AI의 기억은 그 세션에 실려야 행동이 됩니다. 지시문은 어느 자리에 두었느냐에 따라 실리지 않을 수 있고, 줄이면 판단력도 함께 줄며, 메모리에 새로 적은 것은 다음 세션부터 작동합니다. 그리고 기록은 적은 그날의 사실이라서, 「안 된다」거나 「주소가 이것이다」 같은 기록은 지금 다시 재고 말합니다.
1. 지시문이 실리는 자리부터 본다
조직의 AI가 「자료를 못 본다」고 하면 권한이나 접속보다 그 지시문이 그 세션에 실렸는지부터 봅니다. 두 협동조합에서 사설망과 접속과 데이터베이스 권한이 모두 살아 있었는데도 담당자의 AI가 조합 데이터베이스가 있다는 것 자체를 몰랐던 사례가 현장에서 손을 쓰는 법의 5절에 있습니다.
같은 현장에서 정한 처방은 두 가지입니다.
- 지시문의 원본은 한 곳에만 두고, AI가 어느 폴더에서 시작하든 읽는 사용자 단위 지시문에 그 원본을 참조하는 한 줄만 넣습니다. 사본을 여러 벌 만들면 한쪽만 고쳐져서 AI가 낡은 쪽을 전부로 읽게 됩니다.
- 실렸는지는 파일이 있는지로 판정하지 않고, 그 지시문에만 적힌 지식을 그 자리에서 물어 맞히는지로 판정합니다. 데이터베이스의 표 개수 같은 질문은 AI가 스스로 뒤져 맞힐 수 있어서 증거가 되지 못하므로, 그 조직만의 규칙 한 줄을 묻습니다.
2. 지시문을 줄이면 판단력도 준다
우리 기록에 따르면 매 세션 싣는 지시문의 내용을 다른 문서와 다른 AI로 나눠 옮겨서 줄였더니, 같은 날 본부 AI의 사전 확인 습관이 눈에 띄게 약해졌습니다. 모델 이름을 확인하지 않고 찍어서 세 번 연달아 실패했고, 데이터 형식을 미리 보지 않았으며, 풀어야 할 일을 사람에게 넘겼습니다. 컨텍스트에 없는 것은 행동으로도 나타나지 않습니다.
그 뒤로 지시문을 줄일 때는 줄마다 「이것을 빼면 AI가 실수하는가」를 묻고, 판단 기준과 확인 습관은 남깁니다. 반드시 지켜야 하는 규칙은 지시문에 적어 두는 것으로는 다 지켜지지 않으므로 훅 같은 장치로 막습니다. 그 방법은 같은 실수가 두 번이면 훅에 있고, 지시문을 세 계층으로 나누는 구조 자체는 LLM 위키 구축 안내에 있습니다.
3. 줄이기 전에 꺼내 오는 통로를 만든다
우리 기록에 따르면 매 턴 통째로 싣는 메모리 목차가 길어서 아깝다는 이유로 목차부터 깎으려 한 적이 있습니다. 깎기 전에 재 보니, 그동안 AI가 목차에 없는 메모리를 스스로 찾아 꺼낸 횟수가 한 번도 없었습니다. 그 상태에서 목차를 깎으면 빠진 항목은 존재 자체를 알 길이 없어집니다. 우리는 순서를 뒤집어서, 먼저 꺼내 오는 통로를 만들고, 그 통로의 합격선을 숫자로 정해 검증한 뒤에야 목차를 줄였습니다.
통로가 없으면 목차를 깎아도 다시 불어난다는 것도 같은 기록에 있습니다. 찾아 쓸 길이 없으니 본문 요약을 목차에 복사해 넣는 이중 보관을 계속하게 되기 때문입니다.
우리가 만든 회상 통로는 이렇게 생겼습니다.
- 사용자가 프롬프트를 낼 때마다 메모리 목차와 각 메모리의 설명과 본문을 차례로 검색해, 관련된 몇 줄만 그 대화에 넣어 줍니다.
- 넣어 준 줄은 대화 이력에 계속 쌓이므로 상한을 셋 겁니다. 프롬프트 하나에 넣는 줄 수, 한 세션에 넣는 총 횟수, 같은 세션에서 같은 줄을 다시 넣지 않는 것입니다. 상한이 없으면 목차를 줄여 아낀 것보다 더 많이 씁니다.
- 검색은 낱말 검색을 기본으로 둡니다. 임베딩 검색은 시간 제한이 짧은 훅 안에서 실패하면 아무 말 없이 0줄이 되어 분실과 구별되지 않습니다.
이 통로가 목차의 각 줄을 검색어로 쓰고 있었기 때문에, 목차를 줄이는 순간 검색어도 함께 사라진다는 함정이 뒤에 드러났습니다. 목차를 다듬을 때마다 같은 프롬프트 묶음을 다시 돌려 회상률이 떨어지지 않았는지 보는 회귀 시험을 두었고, 결국 매 세션 싣는 목차와 검색용 색인을 따로 떼어 놓았습니다. 둘을 떼어 놓은 뒤에는 매 세션 싣는 목차를 통째로 비워도 회상률이 그대로였습니다. 그때부터 목차를 얼마나 남길지는 검색이 아니라 세션을 시작할 때 눈으로 훑는 목차로서 쓸모가 있는지로 정합니다.
4. 메모리에 적었다고 지금 바뀌지 않는다
기록에 따르면 「선택지를 늘어놓지 말고 권하는 안 하나를 들고 오라」는 지적을 받고 AI가 바로 메모리에 저장한 일이 있었습니다. 그런데 1분 뒤 다음 응답에서 또 선택지 두 개를 늘어놓고 어느 쪽이 좋으냐고 물었습니다. 메모리는 세션이 시작될 때 한 번 실리는 것이라 같은 세션 안의 행동을 바꾸지 않습니다. 저장이 오히려 「이제 됐다」는 안심이 되어 버렸습니다.
지적을 받으면 두 가지를 같이 합니다.
- 메모리에 저장해 다음 세션에 대비합니다.
- 응답을 보내기 직전에 스스로 묻습니다. 지금 또 선택지를 늘어놓고 있지 않은지, 또 묻고 있지 않은지, 내가 할 결정을 또 넘기고 있지 않은지를 확인하고, 걸리면 보내기 전에 고칩니다.
5. 기록은 그때의 사실이다
어느 날 본부 AI가 예전 인수인계 문서에 적힌 「이 모델은 국적 제한 때문에 못 쓴다」는 기록만 보고, 동료 AI는 그 모델을 쓸 수 없다고 단정했습니다. 그런데 그 순간 본부 AI 자신이 바로 그 모델로 돌고 있었습니다. 기록은 몇 주 전의 관측이었고, 실제로 재 보니 그 동료 AI도 문제없이 그 모델을 불렀습니다. 내가 돌고 있는 환경 자체가 기록을 반박하는 첫 증거일 수 있으니, 「막혔다」거나 「안 된다」는 기록은 지금 다시 재 본 뒤에만 말합니다.
반대 방향의 실수도 기록에 있습니다.
- 서버 주소와 버전과 서비스 등록과 인증 방식이 바뀌었다는 보고를 받고 「잘 됐네요」라고만 답한 일이 있었습니다. 적어 두지 않으면 다음 세션의 AI는 옛 주소로 접속합니다. 그런 보고를 받으면 감상보다 기록을 먼저 합니다.
- 한 의료사협 원장의 AI 비서가 새 기계로 이사한 뒤, 그 AI가 스스로 읽는 안내 문서의 주소 표는 고치지 않았습니다. 원장이 파일 올릴 주소를 묻자 AI는 그 표를 보고 이미 닫힌 옛 주소를 알려 드렸습니다. AI의 잘못이 아니라 이사하면서 문서를 고치지 않은 쪽의 잘못이었습니다. 이사를 마쳤다면 그 AI가 읽는 문서 전체에서 새 주소를 검색해 봅니다. 옛 주소가 남았는지 보는 것보다 새 주소가 한 번이라도 적혀 있는지가 더 중요합니다. 0건이면 그 AI는 자기 주소를 모릅니다.
6. 만든 것을 매번 코드로 다시 알아내지 않는다
기록을 보면 한 매장의 업무 자동화 프로그램이 스물네 개 넘게 여러 곳에 흩어져 돌고 있었는데, 본부 AI는 세션마다 코드를 다시 읽어 「이게 무슨 프로그램이었지」를 알아냈습니다. 원인은 프로그램 목록을 한 장에 정리한 정본이 없었던 데 있었습니다.
- 자동화 시스템은 정본 목록 한 장부터 만듭니다. 프로그램마다 목적, 실행 형태, 언제 도는지, 무엇을 받고 내놓는지, 무엇에 기대는지, 코드에 박혀 있는 값을 표로 적고, 코드는 고칠 때만 엽니다.
- 큰 코드 묶음을 처음 조사할 때는 하위 AI 여럿에게 갈래를 나눠 읽기 전용으로 맡기고 결과를 합칩니다. 우리 경우엔 여섯 갈래로 나눠 한 번에 전부를 훑었습니다.
일을 시작할 때 왜 하는지를 적어 두는 방법은 왜부터 적는다에 있습니다.
도구 메모
- 지시문이 실렸는지: 그 폴더에서 새 세션을 열고 그 지시문에만 있는 규칙 한 줄을 물어본다
- 회상 통로의 상한: 프롬프트당 줄 수, 세션당 횟수, 같은 줄 재주입 금지를 숫자로 정해 둔다
- 이사 뒤 점검: AI가 읽는 문서 전체에서 옛 주소와 새 주소를 각각 검색하고, 새 주소 0건이면 고친다