첫 번째 난관: RAG 파이프라인에 "보이지 않는" 컨텍스트 주입 레이어가 있습니다.
3개월 전에 저는 대형 모델을 기반으로 한 고객 서비스 지원 프로젝트를 맡았습니다. 작업 자체는 복잡하지 않습니다. 지식 베이스에서 관련 문서를 검색하고 프롬프트를 입력하면 모델이 대답하게 됩니다. 초기 프로토타입은 원활하게 작동했지만 생산에 들어간 후에는 충돌이 발생했습니다. 모델은 검색된 콘텐츠를 자주 무시하고 때때로 자체 답변을 작성했습니다.
이틀 간의 문제 해결 끝에 문제가 검색에 있는 것이 아니라 프롬프트 구성 레이어에 있다는 것을 마침내 확인했습니다. 코드에는 검색된 텍스트를 시스템 메시지에 직접 삽입하지만 토큰 순서, 중복 정보 및 역할 식별을 고려하지 않는 논리가 있습니다. 결과적으로 모델은 명확한 컨텍스트 대신 "노이즈 더미"를 갖게 됩니다. Context Engineering의 실제 내용을 진지하게 접한 것은 이번이 처음이었습니다. 이는 단순한 프롬프트 연결이 아니라 구조화, 우선 순위 지정 및 일관성을 담당하는 전용 엔지니어링 계층이었습니다.
내 판단 방식을 크게 변화시킨 세 가지 결론
1. 컨텍스트가 많을수록 좋지만 "정렬"될수록 좋습니다.
초기에는 항상 검색결과를 다 넣고 싶었고, 놓칠까봐 걱정도 되었어요. 그러나 프로덕션 로그에 따르면 컨텍스트 길이가 모델이 효과적으로 활용할 수 있는 창(예: 4K 토큰)을 초과하면 정확도가 감소하는 것으로 나타났습니다. 나중에 "관련성 점수 + 동적 자르기"로 전환했습니다. 상위 3개 클립만 유지하고 각 클립이 200개 토큰을 초과하지 않도록 했습니다. 결과는 즉각 나타났습니다. 답변 정확도가 68%에서 91%로 증가했습니다.
2. 컨텍스트 주입 순서는 추론의 질에 직접적인 영향을 미칩니다
처음에는 지식 기반 조각을 사용자 메시지 끝에 배치하는 것이 가장 간단할 것이라고 생각했습니다. 결과 모델은 후반부를 무시하는 경우가 많습니다. 문헌을 검토한 후 모델이 시작(우위 효과)과 끝(최근 효과)에 더 민감하다는 것을 발견했습니다. 그래서 가장 중요한 사실을 시스템 메시지의 시작 부분에 배치하고 보조 정보를 사용자 메시지의 끝 부분에 배치했습니다. 조정 후에는 주요 정보에 대한 인용이 55%에서 87%로 증가했습니다.
3. 컨텍스트에 대한 "명시적인 경계"를 디자인해야 합니다.
모델은 어떤 콘텐츠가 지식 기반의 권위 있는 사실인지, 어떤 콘텐츠가 사용자 자신의 추측인지 알 수 없습니다. 이전에는 태그를 추가하지 않았기 때문에 모델에서는 사용자가 무심코 말한 잘못된 정보를 사실로 간주하는 경우가 많았습니다. 나중에 각 지식 조각 앞에 [来源：知识库]을 추가하도록 강요하고 시스템 메시지에 "정보가 출처를 표시할 때만 사용하고 그렇지 않으면 무시합니다."라는 명확한 지침을 만들었습니다. 이것은 간단해 보이지만 환상을 크게 줄여줍니다.
우리가 직면한 세 가지 함정과 이를 해결하는 방법
함정 1: 컨텍스트 주입 지점이 잘못된 위치에 있습니다.
처음에는 API 호출 이전에 모든 컨텍스트 처리 로직을 함수에 넣고 서비스로 분리하지 않았습니다. 결과적으로 주입 전략을 조정할 때마다 비즈니스 코드를 변경해야 했습니다. 배포 주기는 3일이었고 반복 속도가 매우 느렸습니다. 정정: Context Engineering를 독립된 미들웨어 레이어로 분할하고 구성 드라이버를 통해 전략을 주입합니다. 변경 후 실험 반복은 몇 시간으로 단축되었습니다.
함정 2: 컨텍스트 충돌 처리를 잊어버리는 것
테스트에서 지식 베이스는 "제품 A의 가격은 100위안"과 "제품 A의 가격은 150위안(할인 전)"이라는 두 가지 모순된 버전을 동시에 반환했습니다. 모델은 무작위로 하나를 선택하여 사용자가 이를 반복적으로 확인하게 했습니다. 수정: 충돌 감지 논리가 추가되었습니다. 동일한 엔터티에 대해 서로 다른 값이 나타나는 경우 두 버전이 자동으로 표시되고 소스와 유효 기간이 표시됩니다. 이후 사용자 불만이 80% 감소했습니다.
함정 3: 컨텍스트 캐싱의 영향을 과소평가
중복 토큰을 줄이기 위해 모델 API의 컨텍스트 캐싱 기능을 사용했습니다. 하지만 캐시 키 디자인이 너무 거칠다는 점은 눈치 채지 못했습니다. 시스템 프롬프트가 변경되지 않는 한 캐시는 재사용됩니다. 결과적으로 사용자의 질문이 다른 경우 캐시는 여전히 이전 컨텍스트를 사용하므로 답변이 올바르지 않게 됩니다. 수정: 사용자 쿼리의 다이제스트 해시를 캐시 키에 추가합니다. 그 후 캐시 적중률은 10%만 떨어졌지만 일관성 질문에 대한 답은 0으로 돌아갔습니다.
가장 먼저 복사해야 할 가장 가치 있는 단계: 로그부터 시작
Context Engineering도 도입하고 싶다면 전략을 먼저 작성하지 말고 로그를 먼저 작성하세요. 구체적인 방법:
- 컨텍스트를 주입하는 코드에서 주입 시 토큰 수, 각 조각의 소스, 우선 순위 점수 및 주입 위치를 포함하는 "컨텍스트 감사 로그"를 출력합니다.
- '주입된 것'과 '모델에 실제로 사용된 것'을 비교한다. 간단한 방법은 각 요청 후에 최종 생성된 프롬프트(컨텍스트 포함)를 기록한 다음 수동으로 확인하는 것입니다.
- 매주 맥락 품질 보고서를 생성합니다. 어떤 부분이 무시되고, 어떤 부분이 잘못 인용되고, 어떤 부분이 환각으로 이어지는지 확인합니다.
이 습관을 기르면 추측에 의존하지 않고 데이터 기반으로 전략을 최적화할 수 있습니다. 우리 팀은 2주 동안 로그를 사용했고 이전의 모든 전략에서 허점을 발견했습니다.
지속해야 할 때와 경로를 변경해야 할 때
Context Engineering의 유효 경계는 시스템이 관련성이 높은 소스 텍스트를 안정적으로 얻을 수 있는지 여부에 있습니다. 장기간 검색 재현율이 40% 미만인 경우 검색을 먼저 수정하고 문맥적 방법으로 보완하려고 하지 마십시오. 모델이 여러 라운드의 대화에서 컨텍스트를 자주 잃는 경우 주입 전략을 반복적으로 작성하는 대신 확장 창 모델 또는 플러그인 메모리 모듈에 우선순위를 두십시오.
또한 팀이 매주 컨텍스트 형식을 조정하는 데 50% 이상의 시간을 소비하지만 효과가 명확하지 않은 경우 구조화된 출력 제약 조건으로 전환해야 할지 아니면 모델을 미세 조정해야 할지 잠시 멈추고 평가하는 것이 좋습니다. 저는 한 팀이 반년 동안 주입 전략을 5번이나 변경했는데 정확도가 항상 75%에 머물렀던 사례를 본 적이 있습니다. 나중에 그들은 구조화된 사실을 직접 추출하기 위해 함수 호출을 사용하는 방식으로 전환했고 정확도는 94%로 곧바로 뛰어올랐습니다.
전환 방향의 다음 단계
Context Engineering은 AI 엔지니어링 시스템의 링크일 뿐입니다. 평범한 개발자에서 에이전트 시스템을 독립적으로 설계하고 최적화할 수 있는 엔지니어로 변신하고 싶다면 컨텍스트 관리, 도구 오케스트레이션, 루프 제어 등 고급 주제를 자세히 다루는 우리 팀이 편집한 유료 기사 시리즈 "에이전트 엔지니어링 실습"을 읽어 보시기 바랍니다.
아직 댓글이 없습니다