모델, 맥락, 잘못된 답변

능력과 사용 가능한 정보를 구분하세요

언어 모델은 학습한 패턴과 작업 중 제공된 정보를 사용합니다. 최신 모델은 상당한 추론과 유용한 소프트웨어 작업을 할 수 있습니다. 잘못된 가정에 의존하는 상세한 답변을 만들 수도 있습니다.

“프런티어 모델”은 계속 변하는 능력 수준을 뜻합니다. 이 이름은 모델이 저장소를 읽었다는 사실을 입증하지 않습니다. 의존성 버전이나 문서에 없는 업무 규칙을 안다는 뜻도 아닙니다. 작업 환경에서 이 사실을 제공해야 합니다.

적절한 도구가 있는 에이전트는 정보를 가져올 수 있습니다. 접근 권한이 없는 채팅은 저장소를 조사할 수 없습니다. 답변이 틀린 것 같다면 두 가지를 물으세요. 모델이 올바른 정보를 받으면 이 문제를 풀 수 있나요? 모델이 그 정보를 받았나요?

첫 번째 문제에는 다른 모델이 도움이 될 수 있습니다. 두 번째 문제는 빠진 정책을 제공하거나 의존성을 확인해 해결할 수 있습니다.

맥락은 현재 답변에 사용할 수 있는 정보입니다. 지침, 제공된 파일, 관련 대화, 도구 결과가 포함됩니다. 제품마다 이 정보를 선택하고 유지하는 방식이 다릅니다. 이전 내용을 요약하기도 합니다.

모델이 업로드한 폴더의 모든 파일을 읽는다고 가정하지 마세요. 긴 세션 내내 초기 지침을 사용할 수 있다고 가정해서도 안 됩니다. 도구에 사용한 파일과 지침을 밝히도록 요청하세요.

맥락이 많다고 답변이 항상 좋아지지는 않습니다. 최신 아키텍처 결정 하나가 관련 없는 소스 파일보다 도움이 될 수 있습니다. 폐기된 마이그레이션 가이드를 권위 있는 자료로 받아들이면 잘못된 답변을 낼 수 있습니다.

가상의 계정 설정 기능을 생각해 보세요. 라우트, 인가 미들웨어, 관련 데이터 모델, 기존 테스트를 제공하세요. “구성원은 표시 이름을 바꿀 수 있다. 조직 역할은 바꿀 수 없다”라는 구체적인 제약도 추가하세요. 이제 모델이 지켜야 할 규칙이 명확합니다.

미들웨어가 소유권을 확인하므로 엔드포인트가 안전하다는 답변이 나올 수 있습니다. 이 주장의 각 부분을 검증하세요.

저장소 참조는 살펴볼 위치를 알려 줍니다. 참조가 있다고 설명이 코드와 일치하는 것은 아닙니다.

API 추천에도 같은 방법을 쓰세요. 생성된 코드가 설치된 패키지에서 내보내지 않는 메서드를 호출할 수 있습니다. 의존성을 교체하기 전에 패키지 버전과 공식 문서를 확인하세요. 근거 없는 가정으로 불필요한 마이그레이션을 하게 될 수 있습니다.

“정확하게 하세요”는 검증 계획이 아닙니다. 가정, 필요한 증거, 결과가 틀렸을 때의 영향을 정하세요.

예를 들어 이렇게 지시하세요. “이 엔드포인트의 테넌트 격리는 아직 검증하지 않았습니다. 요청 핸들러를 조사하세요. 다른 테넌트의 사용자가 같은 레코드를 요청하는 테스트를 추가하세요.” 에이전트에게 구체적인 조사 대상과 관찰할 결과를 제공합니다.

구현 질문에서는 실제 시스템 버전을 조사하세요. 문서는 의도한 동작을 설명할 수 있습니다. 코드 조사와 테스트는 현재 동작을 확인하는 데 도움이 됩니다. 둘이 다르면 담당자가 해결할 때까지 차이를 기록하세요. 편리한 답변을 조용히 고르지 마세요.

관리자는 모든 코드 변경을 읽지 않고도 이 방법을 사용할 수 있습니다. 팀이 어떤 가정을 확인했는지 물으세요. 아직 해결하지 못한 가정과 담당자를 확인하세요. 이런 정보가 모델 이름보다 릴리스 결정에 더 직접적인 도움이 됩니다.