6.3

View in English

6.3 생성형 AI와 LLM 애플리케이션

개요와 동기

생성형 AI, 특히 대규모 언어 모델(LLM)은 자연어 지시로 유창한 텍스트, 코드, 요약, 구조화된 데이터를 만들어 낼 수 있습니다. 그래서 어시스턴트, 검색, 문서 처리, 자동화를 위한 강력한 구성 요소가 됩니다. 그러나 그 강점에는 독특한 위험 프로필이 따릅니다. LLM은 확률적입니다. 확신에 찬 거짓(환각)을 만들어 낼 수 있습니다. 프롬프트를 어떻게 쓰느냐에 민감합니다. 그리고 프롬프트 인젝션(모델의 행동을 가로채려고 입력에 몰래 끼워 넣은 악의적 지시) 같은 새로운 공격 표면을 엽니다. 그래서 믿을 만한 LLM 애플리케이션을 만드는 일은 모델보다 그 둘레의 엔지니어링에 더 가깝습니다. 컨텍스트를 어떻게 공급하고, 답을 신뢰할 수 있는 지식에 어떻게 근거시키고, 출력을 어떻게 제약하고, 품질을 어떻게 평가하느냐입니다.

큰 팀에게 LLM 애플리케이션은 전통적 소프트웨어와 고전적 머신러닝 모두와 다른 새로운 패턴을 요구합니다. 학습 단계가 없는 경우가 많습니다. 대신 행동은 프롬프트, 검색된 컨텍스트, 도구 정의, 가드레일(모델의 입력과 출력을 제약하는 런타임 검사)로 빚어집니다. 이는 엔지니어링 노력을 컨텍스트 관리, 검색 품질, 오케스트레이션, 평가 쪽으로 옮깁니다. LLM을 대규모로 도입하는 기업은 모든 팀이 같은 실패 모드를 어렵게 다시 발견하지 않도록 공유 패턴이 필요합니다.

정부와 규제 조직은 추가 요구에 직면합니다. 정책 인용을 지어내거나 민감한 데이터를 유출하는 LLM은 단순한 버그가 아닙니다. 법적 또는 안전 사고가 될 수 있습니다. 이런 환경은 권위 있는 출처에 대한 근거 제시, 엄격한 출력 검증, 중대한 출력에 대한 사람의 감독, 시스템이 무엇을 요청받았고 무엇을 만들어 냈는지의 분명한 기록을 필요로 합니다. 이 장의 기법인 검색 증강 생성, 가드레일, 엄격한 평가가 LLM을 고위험 맥락에 배포할 만큼 안전하게 만듭니다. Anthropic의 Claude 모델은 여러 유능한 제공자 중 하나의 선도적 옵션입니다. 여기의 실천은 어떤 모델을 고르든 적용됩니다.

핵심 원칙

  • 모델이 외운 것에 의존하는 대신 신뢰할 수 있는 지식에 모델을 근거시키십시오.
  • 프롬프트와 컨텍스트를 버려지는 문자열이 아니라 엔지니어링되고 버전 관리되는 산출물로 다루십시오.
  • 모델이 틀리거나 조작될 수 있다고 가정하십시오. 출력을 검증하고 행동을 제약하십시오.
  • 오류와 공격 표면을 줄이도록 모델에 필요한 컨텍스트와 도구만, 그 이상은 주지 마십시오.
  • 오프라인 테스트 세트, 온라인 지표, 사람의 판단으로 지속적으로 평가하십시오.
  • 중대한 출력에는 사람을 루프에 두십시오.
  • 모델을 신뢰되는 시스템 안의 신뢰할 수 없는 구성 요소로 설계하십시오.

권장 사항

프롬프트를 엔지니어링하고 컨텍스트를 의도적으로 관리한다

프롬프트를 코드처럼 다루십시오. 버전 관리에 저장하고, 변경을 리뷰하고, 예시 스위트에 대해 테스트하십시오. 각 프롬프트를 분명하게 구조화하십시오. 역할과 과업, 제약, 형식 요건, 도움이 되는 곳에는 예시입니다. 컨텍스트 윈도우(모델이 한 번에 고려할 수 있는 고정된 텍스트 범위)를 희소 자원으로 다루십시오. 가장 관련 있는 정보를 포함하고, 신중히 순서를 정하고, 잡음을 걷어내십시오. 관련 없거나 과도한 컨텍스트는 품질을 떨어뜨리고 비용을 올리기 때문입니다. 멀티턴 애플리케이션에서는 대화 상태를 명시적으로 관리하여, 중요한 것은 유지하면서 한도 내에 머물도록 이력을 요약하거나 자르십시오. 모델이 바뀌는 순간 깨지는 정교한 속임수보다 분명한 지시와 퓨샷 예시(프롬프트에 포함된 소수의 작동 시연)를 선호하십시오.

검색 증강 생성(RAG)으로 답을 근거시킨다

지식 집약적 과업에서는 신뢰할 수 있는 말뭉치에서 관련 문서를 검색해 모델에 컨텍스트로 제공하고, 그 자료로만 답하고 출처를 인용하라고 말하십시오. RAG는 재학습 없이 지식을 최신으로 유지하고, 답을 승인된 콘텐츠에 한정하며, 인용과 검증을 가능하게 합니다. 검색 품질에 투자하십시오. 문서를 합리적으로 조각내고, 영역에 맞는 임베딩(비슷한 의미를 가까이 놓는 숫자 벡터 표현)을 고르고, 검색된 구절이 실제로 답을 담고 있는지 확인하십시오. 잘못된 구절 위에 세운 유창한 답은 답이 없는 것보다 나쁘기 때문입니다. 그리고 관련된 것이 나오지 않으면 내용을 지어내지 말고 그렇다고 말하게 하십시오.

에이전트와 도구 사용을 절제해서 만든다

LLM은 도구(검색, 데이터베이스, 계산기, 내부 API)를 호출할 수 있고 여러 단계에 걸쳐 계획하고 행동하는 에이전트로 구성될 수 있습니다. 이는 실제 역량을 더하지만 위험도 곱합니다. 모든 도구는 틀리거나 조작된 모델이 해를 입힐 수 있는 또 하나의 방법입니다. 정확한 스키마로 도구를 정의하고, 모든 인수를 검증하고, 최소 권한을 적용하고, 통신 발송이나 송금 같은 중대한 행동에는 확인이나 사람의 승인을 요구하십시오. 에이전트 루프를 제한되고, 관찰 가능하고, 중단 가능하게 유지하십시오. 개방형 자율성에 손을 뻗기 전에 엄격히 범위가 정해진 단일 목적 도구로 시작하십시오.

가드레일을 더하고 출력을 검증한다

모델을 방어의 층으로 감싸십시오. 들어가는 길에서는 특히 신뢰할 수 없는 콘텐츠(웹 페이지, 사용자 문서)가 컨텍스트에 들어올 때 프롬프트 인젝션을 걸러 내고 탐지하십시오. 나가는 길에서는 스키마에 대해 구조를 검증하고, 주장을 출처에 대조하고, 안전하지 않거나 컴플라이언스에 맞지 않는 콘텐츠를 걸러 내고, 검증이 실패하면 거부하거나 재시도하십시오. 구조화된 출력에서는 모델의 형식을 믿는 대신 파싱하고 확인하십시오. 검증 없이 원시 모델 출력이 되돌릴 수 없는 행동을 촉발하게 두지 마십시오. 환각 완화를 모델이 스스로 관리하는 것이 아니라 근거 제시, 인용, 검증, 사람 리뷰로 달성하는 시스템 속성으로 다루십시오.

오프라인, 온라인, 사람으로 평가한다

알려진 정답이나 루브릭으로 점수가 매겨진 출력이 있는 대표적 입력의 평가 스위트를 만들고, 모든 프롬프트나 모델 변경마다 돌리십시오(오프라인 평가). 과업 성공, 에스컬레이션 비율, 사용자 피드백 같은 지표로 프로덕션의 실제 행동을 측정하십시오(온라인 평가). 주관적 품질에는 사람 리뷰어를, 신중하게 모델 기반 채점을 쓰십시오. 평가는 자신감을 갖고 프롬프트와 모델을 바꿀 수 있게 하는 안전망입니다. 없으면 눈 감고 비행하는 것입니다.

장단점

선택장점단점가장 적합한 때
순수 프롬프팅단순하고 빠르며 바꾸기 쌈제한된 근거 제시. 환각 가능넓은 과업. 낮은 판돈
RAG최신이고 근거가 있으며 인용 가능검색을 제대로 하기 어려움지식 집약적이고 사실적인 과업
도구가 있는 에이전트강력하고 행동할 수 있음더 큰 공격 표면. 통제가 더 어려움가드레일이 있는 잘 범위가 정해진 자동화
더 크고 강한 모델더 나은 품질과 추론더 높은 비용과 지연복잡하거나 고위험 과업
더 작고 싼 모델빠르고 저렴어려운 과업에 약함대량의 단순한 과업

핵심 긴장은 역량 대 통제와 비용입니다. 더 많은 자율성과 더 큰 모델은 더 많은 가치를 주지만 더 많은 가드레일, 더 많은 평가, 더 많은 돈을 요구합니다. RAG를 통한 근거 제시는 검색 엔지니어링의 대가로 신뢰성을 높입니다. 올바른 균형은 판돈에 달려 있습니다. 고위험 애플리케이션은 비용이 더 들더라도 근거 제시, 검증, 사람의 감독 쪽으로 기웁니다.

팀과 논의할 질문

  1. LLM 기능이 대중 앞에 서기 전에 넘어야 할 정확도와 근거 제시의 기준은 무엇이며, 누가 승인합니까? 잘못된 출처를 인용하거나 정책을 지어내는 유창한 답은 답이 없는 것보다 나쁘고, 정부에서 지어낸 인용은 버그가 아니라 법적 사고입니다. 큰 팀에서는 명시적 기준이 각 그룹이 느낌으로 자기만의 비공개 임계값을 정하는 것을 막습니다. “충분히 근거가 있다”의 정의를 가져오십시오. 모든 주장이 검색되고 검증된 출처로 추적되어야 하는지, 검색이 비어 있을 때 시스템이 거부해야 하는지, 적대적 평가 세트가 실제로 무엇을 덮는지입니다. 지켜볼 신호는 지금 누군가 회귀 실행 없이 프롬프트 변경을 사용자에게 곧장 출하할 수 있는가입니다. 판돈이 법적이거나 안전 관련이라면, 답은 가장 위험한 출력을 출시 전에 실질적 권한을 가진 사람 리뷰어를 거치게 해야 합니다.

  2. 우리 LLM 기능 중 어느 것이 몰래 에이전트이며, 각 도구에 최소 권한과 되돌릴 수 없는 행동에 대한 사람의 관문이 주어졌습니까? 모델이 도구를 호출하거나 여러 단계에 걸쳐 행동하게 하는 기능은 모두 에이전트 영역으로 넘어갔고, 모든 도구는 틀리거나 조작된 모델이 해를 입히는 또 하나의 방법입니다. LLM을 내부 API에 연결하는 기업에서는 이 질문이 “단순한 어시스턴트”라는 이름표가 숨기는 위험을 드러냅니다. 모델이 호출할 수 있는 모든 도구의 목록, 인수 검증, 권한 범위, 어떤 행동(통신 발송, 송금, 기록 변경)이 확인을 요구하는지 가져오십시오. 에이전트 루프가 제한되고, 관찰 가능하고, 중단 가능한지 논의하십시오. 답은 중대하거나 되돌릴 수 없는 행동에 지금 관문 없이 닿을 수 있는 곳이면 어디든 범위를 조이고 사람의 승인 관문을 더해야 합니다.

  3. 확신에 찬 답이 잘못된 구절 위에 세워져도 괜찮아 보이는데, 검색 품질이 떨어졌음을 하루 안에 어떻게 알겠습니까? RAG는 검색이 답을 담은 구절을 실제로 드러낼 때만 답을 신뢰할 수 있게 하며, 검색은 문서가 바뀌고, 청크가 낡고, 임베딩이 영역에서 드리프트함에 따라 조용히 썩습니다. 모델이 나쁜 컨텍스트 위에서도 여전히 유창하게 쓰기 때문에, 사용자는 신뢰가 이미 사라진 뒤에야 불평할 수 있습니다. 검색 지연과 재현율의 현재 측정, 검색된 구절이 정말 답을 담고 있는지 확인하는 방법, 색인 신선도가 문서 변경을 따라가는 방식을 가져오십시오. 고위험이나 공개 배포에서는 나쁜 답을 나쁜 구절까지 추적할 수 있도록 감사를 위해 검색된 출처를 기록하는 것을 논의하십시오. 검색 평가가 전혀 없다면 믿음으로 근거를 제시하고 있는 것입니다.

  4. 프롬프트, 컨텍스트, 평가 세트를 버전 관리되고 리뷰되는 산출물로 다룹니까, 아니면 노트북과 채팅 로그에 흩어진 문자열로 다룹니까? 프롬프트가 버전 관리 없이 팀 전반에 중복되어 번지면, 한 곳의 수정이 다른 곳에 닿지 않고 아무도 지난 분기에 시스템이 무엇을 요청받았는지 재현할 수 없습니다. 큰 팀에서는 공유 프롬프트 레지스트리와 모든 변경마다 도는 회귀 스위트가, 모델을 바꾸거나 지시를 고쳐도 두 팀 건너의 기능을 조용히 깨뜨리지 않게 해 줍니다. 경쟁하는 끌림은 속도입니다. 엔지니어는 프롬프트를 붙여 넣고 출하할 때 가장 빠르게 반복하므로, 빠른 실험과 사용자에게 닿는 모든 것 사이의 선이 어디인지 합의하십시오. 오늘 프롬프트가 실제로 어디에 사는지, 평가 세트가 변경을 관문 통제하는지, 프롬프트와 나란히 검색 말뭉치의 버전을 어떻게 관리하는지 가져오십시오. 기업과 정부 환경에서는 감사 요건을 더하십시오. 몇 달 뒤 어떤 출력을 만든 정확한 프롬프트와 출처를 보여야 할 수 있고, 재구성할 수 없는 프롬프트는 방어할 수 없는 기록입니다.

  5. 물량이 늘 때 품질을 조용히 떨어뜨리지 않고 추론 비용을 어떻게 통제하며, 모델 선택 결정은 누가 소유합니까? LLM 기능의 TCO는 호출당 추론이 지배하며, 시범 사업에서 하찮아 보이던 비용이 프로덕션 규모에서 빠르게 복리로 쌓여, 팀이 조용히 더 약한 모델로 내려가고 아무도 품질 하락을 알아채지 못하기를 바라게 유혹합니다. 큰 조직에서 각 팀이 느낌으로 모델과 비용 한도를 고르게 두면 깜짝 청구서와 일관성 없는 품질이 모두 생깁니다. 진짜 트레이드오프는 역량 대 비용과 지연입니다. 더 큰 모델은 어려운 과업에서 더 잘 추론하고, 더 작은 모델은 단순한 과업에서 더 싸고 빠르며, 캐싱, 라우팅, 검색 범위가 모두 숫자를 움직입니다. 해결된 과업당 비용, 평가 세트에서 모델 등급별 품질, 프롬프트나 컨텍스트 비대가 토큰 지출을 부풀리는 곳을 가져오십시오. 기업과 정부 예산에서는 누가 모델 선택과 지출 상한을 승인하는지 이름을 정하십시오. 아무도 소유하지 않는 비용 항목은 트래픽이 세 배가 될 때 아무도 통제하지 못하기 때문입니다.

  6. 어떤 민감한 데이터가 모델에 닿을 수 있고, 그 데이터는 어디로 가며, 범위 안에 머물렀음을 증명할 수 있습니까? 모든 프롬프트, 검색된 문서, 도구 결과가 개인 데이터나 기밀 데이터를 모델로, 호스팅 제공자의 경우 경계 밖으로 실어 나를 수 있으며, 여기서의 유출은 결함 티켓이 아니라 법적 또는 안전 사고입니다. LLM을 내부 시스템에 연결하는 큰 팀에서 위험은 배관에 숨어 있습니다. 특정 사용자가 결코 봐서는 안 될 기록을 포함하는 검색 말뭉치, 원시 입력을 포착하는 로그입니다. 긴장은 역량 대 노출입니다. 가림과 엄격한 범위 설정이 만들려는 기능을 무디게 할 수 있기 때문입니다. 컨텍스트에 들어가는 것의 데이터 흐름 지도, 제공자의 보존 및 학습 약관, 민감한 필드를 어떻게 가리고, 범위를 정하고, 기록하는지를 가져오십시오. 규제 및 공공 환경에서는 이를 데이터 거주 규칙, 기록 보존 의무, 벤더가 데이터를 쓸 수 있는 방식에 대한 계약상의 한계에 묶으십시오. 증거로 보일 수 없는 감독은 갖고 있지 않은 감독이기 때문입니다.

분야별 관점

스타트업. 핵심 가치에 닿는 좁은 LLM 기능 하나를, 자체 콘텐츠에 대한 검색과 함께 호스팅 모델 위에 만들어 출하하고, 제공자를 바꿀 수 있도록 프롬프트를 얇은 인터페이스 뒤의 git에 두십시오. 변경마다 실제 질문의 작은 평가 파일을 돌리고, 붙여 넣은 사용자 텍스트를 걸러 프롬프트 인젝션을 무디게 하고, 월간 지출을 엄격히 제한하십시오. 에이전트와 자체 호스팅에 저항하십시오. 감독할 수 없는 무제한 도구 호출 루프는 시연이 아니라 부채입니다.

소기업. ML 전문가가 없을 테니 구축에 인력을 두는 대신 이미 쓰는 도구에 내장된 LLM 기능을 사십시오. 위험을 단순한 질문으로 구성하십시오. 확신에 찬 틀린 답이 어디서 고객을 잃게 하며, 나가기 전에 누가 출력을 확인하는가? 출처를 보여 주고, 사람을 루프에 두게 하고, 잘못 동작할 때 AI를 끄기 쉽게 하는 벤더를 선호하십시오.

대기업. 문제는 많은 팀에 걸친 규모입니다. 각 그룹이 같은 실패 모드를 다시 발견하지 않도록 RAG, 가드레일, 도구 스키마의 공유 패턴과 공통 평가 하네스 및 프롬프트 레지스트리를 공표하십시오. 추론 비용과 사람 리뷰를 명시적으로 예산에 잡고, 모델이 교체 가능하도록 인터페이스 계층을 표준화하고, 최소 권한, 제한된 루프, 감사 로깅으로 에이전트를 중앙에서 다스리십시오. LLM 기능을 흩어진 시범 사업이 아니라 지표와 중단 기준이 있는 포트폴리오로 관리하십시오.

정부. 투명성, 조달 규칙, 책무가 모든 선택을 형성합니다. 인용과 함께 승인된 출처에 엄격히 근거시키고, 검색이 비면 거부하고, 모델이 인용할 수 없는 법을 진술하지 못하게 금지하십시오. 책임 있는 담당자가 중대한 출력을 리뷰하게 하고, 감사를 위해 입력과 검색된 출처를 기록하고, 릴리스마다 적대적 평가 세트를 돌리고, 계약에서 모델 한계와 데이터 처리 약관의 공개를 요구하십시오.

사례

스타트업. 세 명의 개발자 도구 스타트업이 사용자가 기본적인 질문을 이메일로 보내는 것을 멈추도록 자체 문서 위에 채팅 도우미를 더했습니다. 모든 답이 특정 문서 페이지를 인용하도록 RAG를 썼고, 검색이 비면 “잘 모르겠습니다. 이분께 문의하세요”라고 말하도록 모델에 지시했으며, 프롬프트를 git에 두었습니다. 변경마다 회귀를 잡으려고 실제 사용자 질문의 작은 파일에 프롬프트를 돌렸고, 사용자가 붙여 넣은 텍스트를 걸러 프롬프트 인젝션을 무디게 했습니다. 도우미는 흔한 질문을 처리하고 나머지는 조용히 창업자들의 공유 받은편지함으로 넘겼습니다.

기업. 한 소프트웨어 회사가 제품 문서 위에 내부 지원 어시스턴트를 만들었습니다. 답이 특정 문서 페이지를 인용하도록 RAG를 썼고, 검색이 실패하면 “모르겠습니다”라고 말하라고 모델에 지시했으며, 인용된 모든 출처가 실제로 존재하는지 검증했습니다. 프롬프트는 버전 관리되었고 변경마다 실제 지원 질문 스위트에 대해 테스트되었습니다. 어시스턴트는 일상적인 티켓을 줄이고 확신이 낮은 것은 사람 상담원에게 에스컬레이션했으며, 온라인 지표가 해결률과 수정률을 추적했습니다.

정부. 한 공공 기관이 직원이 시민 문의에 대한 답변을 작성하도록 돕는 LLM 어시스턴트를 배포했습니다. 근거 제시는 엄격했습니다. 모델은 인용과 함께 승인된 안내로만 답변을 작성할 수 있었고, 검색된 출처에 없는 정책을 진술하는 것이 금지되었습니다. 책임 있는 담당자가 모든 초안을 나가기 전에 리뷰했습니다. 입력 필터링이 시민이 제출한 문서의 프롬프트 인젝션을 막았고, 출력은 감사를 위해 기록되었으며, 시스템이 법적 사안에 대한 추측을 거부함을 확인하려고 릴리스마다 적대적 및 엣지 케이스 질의 평가 세트가 돌았습니다.

비즈니스 사례: 동기, ROI, TCO

LLM 애플리케이션은 언어 집약적 작업, 곧 질문에 답하기, 문서 요약하기, 콘텐츠 초안 쓰기, 비정형 텍스트에서 구조 추출하기를 자동화해 ROI를 줍니다. 가치는 줄어든 티켓, 더 빠른 초안 작성, 더 적은 수작업 리뷰, 새로운 셀프서비스 역량으로 나타납니다. 학습 단계가 없는 경우가 많아 첫 가치까지의 시간이 짧은 것이 큰 매력입니다.

그러나 TCO는 지속적인 추론 비용, 검색 인프라, 평가 파이프라인, 가드레일 시스템, 사람 리뷰가 지배합니다. 호출당 비용은 규모에서 빠르게 쌓이고, 모니터링되지 않는 애플리케이션은 안전하지 않거나 비싼 행동으로 드리프트할 수 있습니다. 도입하지 않는 비용은 서비스 품질과 직원 생산성에서 뒤처지는 것입니다. 부주의하게 도입하는 비용은 공개적 환각 사고나 데이터 유출입니다. 구체적인 생산성 목표를 구체적인 안전 및 평가 계획과 짝지우고, 가치를 오래가게 하는 가드레일과 사람의 감독에 예산을 잡아 리더십을 설득하십시오.

안티패턴과 함정

  • 유창한 출력 신뢰. 확신에 차고 잘 쓴 텍스트를 올바른 텍스트로 착각하는 것.
  • 검색 평가 없는 RAG. 검색이 동작한다고 가정하고 올바른 구절을 드러내는지 결코 확인하지 않는 것.
  • 프롬프트 인젝션 맹목. 방어 없이 신뢰할 수 없는 콘텐츠를 프롬프트에 넣는 것.
  • 무제한 에이전트. 한도나 사람의 승인 없이 에이전트가 중대한 행동을 하게 두는 것.
  • 평가 하네스 없음. 회귀 테스트 없이 느낌으로 프롬프트와 모델을 바꾸는 것.
  • 프롬프트 난립. 프롬프트가 흩어지고, 버전 관리되지 않고, 팀 전반에 중복되는 것.
  • 과잉 자동화. 법적이거나 안전의 무게가 있는 결정에서 사람을 제거하는 것.

성숙도 모델

  1. 시작. 고립된 프로젝트의 즉흥적 프롬프팅. 근거 제시, 가드레일, 평가 없음. 프롬프트는 누군가 붙여 넣은 곳에 살고, 환각은 프로덕션에서 발견됩니다.
  2. 발전. 일부 팀이 RAG와 프롬프트 버전 관리, 기본적 출력 검증, 작은 수동 평가 세트를 더하지만, 실천은 팀마다 다르고 공유된 기대가 아니라 개인 옹호자에 의존합니다.
  3. 표준화. RAG, 가드레일, 도구 스키마, 프롬프트 버전 관리의 문서화된 패턴이 조직 전체에서 시행됩니다. 자동화된 오프라인 평가가 모든 프롬프트나 모델 변경마다 돌고, 고위험 흐름에는 온라인 지표와 사람 리뷰가 붙습니다.
  4. 관리. 포트폴리오가 기준선에 대해 측정됩니다. 검색 재현율, 환각과 거부율, 인젝션 방어 커버리지, 호출당 비용과 지연, 에스컬레이션과 수정률이 대시보드에서 추적되고, 릴리스 관문과 중단 기준이 의견이 아니라 증거에 따라 작동하며, 회귀 실행이 지표를 잘못된 방향으로 움직이는 모든 변경을 막습니다.
  5. 오케스트레이션. 지속적인 오프라인 및 온라인 평가가 비즈니스 성과에 묶입니다. 인젝션 방어, 에이전트, 근거 제시가 다스려지고 관찰 가능하며, 조직은 품질, 비용, 위험이 이동함에 따라 LLM 기능을 일상적으로 퇴역시키고, 재조정하고, 범위를 다시 정하며 모델을 교체합니다.

논의를 위한 아이디어

  • 어떤 출력이 사용 전에 사람 리뷰를 요구하는지 어떻게 결정합니까?
  • 사용자에게 답을 보여 주기 전에 “충분히 근거가 있다”의 기준은 무엇입니까?
  • 신뢰할 수 없는 콘텐츠가 컨텍스트에 들어와야 할 때 프롬프트 인젝션을 어떻게 방어합니까?
  • 에이전트는 언제 더 단순한 단일 호출 설계에 견주어 추가된 위험만큼 값을 합니까?
  • 모델 기반 채점에 지나치게 의존하지 않고 규모에서 주관적 품질을 어떻게 평가합니까?
  • 많은 팀에 걸쳐 프롬프트를 어떻게 유지보수 가능하고 일관되게 유지합니까?

핵심 요점

  • 믿음직함은 모델 둘레의 엔지니어링, 곧 컨텍스트, 근거 제시, 가드레일, 평가에서 나옵니다.
  • RAG는 답을 신뢰할 수 있는 출처에 근거시키고 인용과 검증을 가능하게 합니다.
  • 모델을 신뢰할 수 없는 구성 요소로 다루십시오. 출력을 검증하고 도구 사용을 제약하십시오.
  • 에이전트에게 최소 권한, 제한된 루프, 중대한 행동에 대한 사람의 승인을 주십시오.
  • 오프라인, 온라인, 사람으로 지속적으로 평가하십시오. 그것이 변경을 안전하게 합니다.

참고 문헌과 더 읽을거리

  • Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
  • Jason Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.
  • OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
  • Chip Huyen, AI Engineering: Building Applications with Foundation Models.
  • Anthropic, Building Effective Agents (engineering guidance).
  • Louis-François Bouchard and Louie Peters, Building LLMs for Production.