dropbox·2026년 6월 25일·3분 읽기큐레이션 요약

DSPy를 활용해 Dash 채팅에서 AI 평가를 더 나은 응답으로 전환한 방법

Dropbox는 Dash chat 에이전트의 최종 답변만 평가하지 않고, 의도 파악·검색·도구 사용·근거 선택·다중 턴 대응까지 전체 실행 과정을 평가했습니다. 이후 사람의 평가 데이터를 활용해 LLM 평가자(judge)를 보정하고, DSPy의 GEPA·MIPROv2로 평가자와 에이전트 시스템 프롬프트를 최적화했습니다. 그 결과 불완전한 답변을 줄이고 토큰 사용량도 낮추면서 답변 품질을 유지할 수 있었습니다. ## 에이전트 평가가 어려운 이유 - 전통적인 검색 평가는 단일 결과의 관련성을 주로 측정하지만, 에이전트는 여러 단계의 의사결정을 수행합니다. - 평가 대상에는 다음 과정이 모두 포함됩니다. - 사용자의 의도 해석 - 문서·메시지·회의 기록 등 적절한 컨텍스트 수집 - 검색 및 문서 읽기 같은 도구 사용 - 여러 출처의 정보 종합 - 직접 답변, 추가 검색, 요약, 명확화 질문 중 적절한 선택 - 대화가 여러 턴에 걸쳐 진행될 수 있으므로 최종 답변뿐 아니라 피드백 반영과 재검색 과정도 평가해야 합니다. - 따라서 답변 품질, 의도 이해, 컨텍스트 선택, 도구 사용, 근거성, 지시 준수, 과업 완료 여부를 পৃথ도로 분석해야 실패 원인을 찾을 수 있습니다. ## 사람의 평가로 LLM judge 보정 - 내부 채팅 샘플과 에이전트 trace 로그를 수집하고, 사람이 다음 다섯 가지 차원을 평가했습니다. - 사용자 의도 추종 - 의미적 관련성 - 도구 호출 품질 - 지시사항 준수 - 컨텍스트 선택 - 평가자는 먼저 의도와 컨텍스트가 적절했는지 확인한 뒤 검색·검색 결과 활용·도구 행동을 검토했습니다. - 이후 최종 답변이 선택된 근거에 의해 뒷받침되는지, 관련성·근거성·완전성·지시 준수 여부를 평가했습니다. - 일부 지표는 1~5점으로 점수화하고, 함께 다음 정보를 기록했습니다. - 점수의 근거가 되는 reasoning note - 오래된 근거, 누락된 컨텍스트, 근거 없는 주장, 불완전한 답변, 개인화 실패 등의 failure code - 점수는 결과를 요약하지만, 평가 메모와 실패 코드는 문제가 발생한 위치와 원인을 보여줍니다. - 이 데이터는 judge 프롬프트 보정뿐 아니라 디버깅, 오류 분석, 개선 로드맵 수립, 우선순위 결정에도 활용됐습니다. ## DSPy를 이용한 평가자 개선 - 목표는 LLM judge의 점수가 사람의 판단과 더 일치하도록 만드는 것이었습니다. - judge는 단순히 답변에 점수를 매기는 것이 아니라 다음과 같은 정해진 절차를 따라야 했습니다. - 사용자의 의도 추론 - 대화 내용 검토 - 에이전트 trace와 지원 근거 확인 - 컨텍스트 선택과 도구 사용 분석 - 점수·실패 코드·평가 메모 작성 - DSPy를 최적화 도구로 사용하고, GEPA와 MIPROv2를 알고리즘으로 활용했습니다. - 알고리즘은 사람의 라벨이 있는 예제에서 프롬프트 변경안을 자동으로 제안하고 테스트했습니다. - 지원한 최적화 방식에는 다음이 포함됩니다. - judge 지침을 처음부터 새로 작성 - 기존 평가 행동을 유지하면서 다른 기반 모델에 맞게 조정 - 특정 실패 유형을 집중적으로 수정하는 타깃 최적화 - 이렇게 최적화된 judge는 이후 채팅 에이전트 자체의 시스템 프롬프트를 개선하는 평가 신호로 사용됐습니다. ## 평가에서 에이전트 개선으로 이어지는 피드백 루프 - 전체 과정은 다음 순환 구조로 구성됩니다. - 사람의 라벨이 judge를 보정 - 개선된 judge가 대규모 평가 신호 생성 - 평가 신호가 에이전트 프롬프트와 행동 개선에 사용 - 이 구조를 통해 사람의 평가를 모든 대화에 직접 적용하지 않고도 에이전트를 반복적으로 최적화할 수 있었습니다. - 최종적으로 불완전한 답변이 크게 줄었고, 답변 품질을 떨어뜨리지 않으면서 토큰 사용량도 절감했습니다. 실무적으로는 에이전트 개선 전에 평가자의 신뢰성을 먼저 검증해야 합니다. 최종 점수만 수집하기보다 trace, 평가 이유, 실패 유형을 함께 기록하고, 사람의 라벨과 DSPy 같은 자동 최적화 도구를 결합하면 평가를 지속적인 품질 개선 시스템으로 전환할 수 있습니다.

원문 읽기(새 탭에서 열림)

prompt-optimization대규모 언어 모델AI 에이전트dspy+4

line·2026년 6월 23일·4분 읽기큐레이션 요약

프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화

프롬프트 튜닝은 반복적인 수작업과 개인 의존성 때문에 수일에서 수주가 걸리지만, 유전 알고리즘 기반의 GEPA를 적용하면 이를 약 한 시간으로 단축할 수 있다. GEPA는 후보 프롬프트를 여러 세대에 걸쳐 평가·변이하고, 점수뿐 아니라 자연어 피드백까지 활용해 개선 방향을 찾는다. LY Corporation은 이를 Yahoo! JAPAN Search의 건강·의료 쿼리에 적용해 정책 준수와 답변 가독성을 함께 최적화했다. ## 프롬프트 튜닝이 어려운 이유 - 프롬프트를 조금만 수정해도 출력을 다시 생성하고 사람이 품질을 판단해야 한다. - 수십~수백 개의 프롬프트 패턴을 시험하는 경우가 있어 반복 작업량이 크다. - “특정 표현이나 지시 순서가 효과적이다” 같은 노하우가 담당자 개인에게 남기 쉽다. - 개선 이유와 시행착오 과정이 기록되기 어려워 재현성과 설명 가능성이 떨어진다. - 모델 버전이 바뀌면 출력 품질도 변하므로 지속적인 재튜닝이 필요하다. - 사람이 직접 해야 할 정책 검증, 평가 기준 정리, 품질 판단에 충분한 시간을 쓰기 어렵다. ## 프롬프트 자동 최적화 방법 - 대표적인 접근법은 다음과 같다. - **강화 학습 기반**: 출력에 대한 스칼라 보상을 이용해 프롬프트 생성 정책을 학습한다. - **베이지안 최적화 기반**: 지시문과 퓨샷 예시를 탐색 공간으로 보고 효율적으로 후보를 선택한다. - **유전 알고리즘 기반**: 여러 프롬프트 후보를 집단으로 관리하며 세대별로 개선한다. - 자연어로 구성된 프롬프트는 이산적인 구조이므로 유전 알고리즘과 잘 맞는다. - 실행 결과와 평가 내용을 자연어로 분석하는 **리플렉션(reflection)**을 통해 단순 점수 이상의 개선 정보를 활용할 수 있다. ## GEPA의 진화적 최적화 루프 - 여러 후보 프롬프트를 생성하고 각 후보를 평가한다. - 점수가 높거나 여러 평가 축에서 균형이 좋은 후보를 선택한다. - 후보의 출력과 피드백을 자연어로 분석해 문제점을 찾는다. - **Reflective Prompt Mutation**을 사용해 기존 프롬프트를 개선한 변이 후보를 생성한다. - 이 과정을 수~수십 세대 반복하면서 평가 기준에 맞는 프롬프트로 수렴시킨다. - 여러 평가 관점을 동시에 고려하기 위해 **Pareto frontier 기반 선택**을 사용한다. - 스칼라 보상 하나에만 의존하는 방식과 달리, “왜 감점됐는가”라는 설명을 개선 과정에 반영할 수 있다. ## DSPy와 GEPA를 이용한 구현 - DSPy에서는 입력과 출력을 정의한 `Signature`, 실행 로직을 담은 `Module`, 예측을 수행하는 `Predict`를 구성한다. - 시그니처의 독스트링은 LLM에 전달되는 인스트럭션으로 사용된다. - GEPA는 이 인스트럭션을 자동으로 재작성해 최적화한다. - 최적화 과정에서 다음 모델을 분리해 설정할 수 있다. - **추론 모델**: 실제 답변을 생성하는 모델 - **평가 모델**: 생성 결과를 채점하는 모델 - **리플렉션 모델**: 평가 결과를 바탕으로 개선 프롬프트를 만드는 모델 - `num_candidates`, `num_generations` 등의 설정으로 후보 수와 세대 수를 조정한다. - 최적화는 학습 예제 집합을 대상으로 `optimizer.compile()`을 실행해 수행한다. ## 평가 함수와 자연어 피드백 - GEPA의 평가 함수는 기본적으로 `score`라는 단일 스칼라 값을 반환해야 한다. - 평가 기준이 여러 개라면 각 점수를 0~10 범위로 계산한 뒤 평균 등을 사용해 하나의 값으로 정규화한다. - 예를 들어 구체성, 정책 준수, 가독성의 점수를 합산해 전체 점수를 만들 수 있다. - 동시에 `feedback` 필드에 감점 이유와 개선 방향을 자연어로 전달할 수 있다. - 점수만 전달하면 “0.6점”이라는 결과만 알 수 있지만, 피드백을 주면 “의료 판단을 단정적으로 표현해 감점됐다”처럼 구체적인 원인을 알 수 있다. - 정답 데이터가 있다면 `gold`를 사용해 기대 출력이나 레이블과 비교할 수 있다. - 정답이 없는 경우에도 LLM-as-a-Judge나 규칙 기반 평가를 사용할 수 있다. - LLM-as-a-Judge를 사용할 때는 평가 기준을 명확히 작성하고, 출력 점수의 범위를 제한하는 등 평가 결과를 정규화해야 한다. ## Yahoo! JAPAN Search 건강·의료 쿼리 적용 - 건강·의료 답변은 일반 쿼리보다 정책 요구가 많다. - 주요 정책에는 다음이 포함된다. - 질병명이나 중증도를 단정하지 않기 - 근거 수준에 맞는 표현 사용하기 - 일반적인 설명 범위를 유지하기 - 필요할 때 의료기관 진료를 권유하기 - 허위 정보나 확증되지 않은 정보를 제공하지 않기 - 동시에 제목, 목록, 강조 등 마크다운 형식을 적용해 가독성도 높여야 했다. - 정책 준수와 가독성은 한쪽을 강화하면 다른 쪽이 약화될 수 있어 사람이 동시에 최적화하기 어렵다. ## 실제 최적화 방식과 기대 효과 - 초기 프롬프트에는 기존 범용 프롬프트와 건강·의료 정책 문구가 단순히 이어 붙어 있었다. - GEPA는 시그니처의 인스트럭션 부분을 재작성하며 두 목표를 동시에 최적화했다. - 평가 함수는 여러 품질 관점의 점수를 집계하고, LLM이 작성한 평가 이유를 리플렉션 피드백으로 제공했다. - 결과적으로 수일~수주가 걸리던 프롬프트 조정 작업을 약 한 시간으로 줄이는 것을 목표로 했다. - 모델 업데이트나 정책 변경 때도 동일한 평가·최적화 파이프라인을 다시 실행할 수 있어 유지보수 자동화에 유리하다. 프롬프트 최적화를 도입할 때는 먼저 정책과 품질 기준을 세분화하고, 점수뿐 아니라 구체적인 자연어 피드백을 평가 함수에 포함하는 것이 중요하다. 다만 LLM 평가자의 편향과 변동성이 결과에 영향을 줄 수 있으므로, 가능하면 규칙 기반 검사와 정답 데이터 기반 평가를 함께 사용해 최적화된 프롬프트를 별도로 검증하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

prompt-optimization대규모 언어 모델llm-as-a-judgedspy+3

aws·2026년 5월 14일·3분 읽기큐레이션 요약

Amazon Bedrock, 새로운 고급 프롬프트 최적화 및 마이그레이션 도구 출시 | Amazon Web Services

Amazon Bedrock의 **Advanced Prompt Optimization**은 여러 모델에서 프롬프트를 자동으로 개선하고, 기존 프롬프트와 최적화된 프롬프트의 성능을 비교하는 도구입니다. 사용자는 예시 입력, 정답 데이터, 평가 기준을 제공하면 되며, 모델 마이그레이션이나 현재 모델의 성능 개선에 활용할 수 있습니다. 최적화 결과로 프롬프트, 평가 점수, 비용 추정치, 지연 시간이 함께 제공됩니다. ## 여러 모델을 동시에 비교하는 프롬프트 최적화 - 최대 5개의 Amazon Bedrock 추론 모델을 선택할 수 있습니다. - 새 모델로 마이그레이션하는 경우: - 현재 모델을 기준선으로 선택 - 최대 4개의 후보 모델과 성능 비교 - 모델을 변경하지 않는 경우에도 현재 모델의 최적화 전후 결과를 비교할 수 있습니다. - 알려진 사용 사례에서 성능 저하가 없는지 확인하거나, 성능이 낮은 작업을 개선하는 데 사용할 수 있습니다. ## 입력 데이터와 JSONL 템플릿 - 프롬프트 템플릿은 JSONL 형식으로 준비해야 합니다. - 각 JSON 객체는 한 줄에 작성해야 합니다. - 주요 필드는 다음과 같습니다. - `version`: 고정값 `bedrock-2026-05-14` - `templateId`: 프롬프트 템플릿 식별자 - `promptTemplate`: 최적화할 프롬프트 - `evaluationSamples`: 입력 변수와 선택적 기준 응답 - `steeringCriteria`: 자연어 기반 최적화 기준 - `customLLMJConfig`: 사용자 정의 LLM 평가 설정 - `evaluationMetricLambdaArn`: Lambda 기반 평가 함수 - 파일은 직접 업로드하거나 Amazon S3에서 가져올 수 있습니다. - 최적화 결과와 평가 데이터가 저장될 S3 출력 위치도 지정할 수 있습니다. ## 멀티모달 프롬프트 지원 - 텍스트 입력뿐 아니라 이미지와 문서가 포함된 프롬프트도 최적화할 수 있습니다. - 지원 파일 형식: - PNG - JPG - PDF - `inputVariablesMultimodal` 필드에 파일 유형과 S3 URI를 지정합니다. - 문서 분석, 이미지 분석과 같은 멀티모달 작업의 프롬프트 개선에 적합합니다. ## 평가 방식 세 가지 ### Lambda 기반 사용자 정의 평가 - 정확도, F1 점수, 실행 정확도, 구조화된 JSON 일치 여부처럼 명확한 수치 평가에 적합합니다. - Python으로 작성한 Lambda 함수에서 모델 응답과 기준 응답을 비교합니다. - `evaluationMetricLambdaArn`을 통해 평가 Lambda를 연결합니다. - 핵심 로직은 모델 출력과 정답을 비교해 점수를 계산하는 `compute_score` 구현입니다. ### LLM-as-a-Judge 평가 - 요약, 생성, 추론 설명처럼 정답이 하나로 정해지지 않은 작업에 적합합니다. - 사용자 정의 평가 프롬프트와 평가 기준, 점수 척도를 설정할 수 있습니다. - Bedrock의 평가 모델이 각 프롬프트와 응답을 평가하고 점수와 판단 근거를 반환합니다. - 기본 평가 모델은 Claude Sonnet 4.6이며, 지원되는 다른 평가 모델을 선택할 수도 있습니다. - 설정은 `customLLMJConfig`에 지정합니다. ### 자연어 기반 Steering Criteria - 브랜드 문체, 출력 형식, 안전 제약 등 원하는 품질을 자연어로 설명할 때 사용합니다. - 직접 복잡한 평가 프롬프트나 점수 체계를 작성하지 않아도 됩니다. - `steeringCriteria` 배열에 원하는 기준을 입력합니다. - 기본 LLM 평가 프롬프트가 해당 기준을 반영해 응답을 종합적으로 평가합니다. - 이 방식에서도 Claude Sonnet 4.6이 평가 모델로 사용됩니다. ## 피드백 루프와 결과 확인 - Bedrock은 프롬프트와 예시 데이터를 선택한 모델에 전달합니다. - 모델 응답을 지정한 평가 방식으로 채점합니다. - 평가 결과를 바탕으로 프롬프트를 다시 작성합니다. - 이 과정을 반복해 평가 지표에 맞는 프롬프트를 탐색합니다. - 최종적으로 다음 정보를 확인할 수 있습니다. - 원본 및 최적화된 프롬프트 템플릿 - 모델별 평가 점수 - 예상 비용 - 응답 지연 시간 - 평가 데이터와 결과 ## 사용 방법과 제공 지역 - Amazon Bedrock 콘솔의 **Advanced Prompt Optimization** 페이지에서 `Create prompt optimization`을 선택합니다. - API를 사용하려면 `CreateAdvancedPromptOptimizationJob`을 호출합니다. - 미국, 아시아 태평양, 캐나다, 유럽, 남미의 여러 리전에서 제공됩니다. - 최적화 과정에서 사용된 Bedrock 모델 추론 토큰에 대해 일반 추론과 동일한 토큰 요금이 부과됩니다. 실무에서는 먼저 정확도나 JSON 일치처럼 측정 가능한 작업은 Lambda 평가로 시작하고, 요약·문체·안전성처럼 정성적인 작업은 LLM-as-a-Judge 또는 Steering Criteria를 사용하는 것이 적합합니다. 모델을 교체할 때는 기존 모델을 기준선으로 포함해 품질뿐 아니라 비용과 지연 시간까지 함께 비교하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)

prompt-optimization대규모 언어 모델amazon-bedrock멀티모달 AI+3

dropbox·2026년 1월 28일원문

엔지니어링 VP 조 (새 탭에서 열림)

Dropbox Dash는 파편화된 기업 내 데이터를 통합하여 사용자에게 최적화된 답변을 제공하기 위해 인덱스 기반의 '컨텍스트 엔진(Context Engine)'과 지식 그래프를 핵심 기술로 활용합니다. 단순히 데이터를 검색하는 것을 넘어 멀티모달 이해와 데이터 간의 관계 모델링을 통해 고도화된 업무 맥락을 파악하며, MCP(Model Context Protocol)가 가진 성능적 한계를 독자적인 최적화 기법으로 해결했습니다. 이를 통해 보안과 권한 관리를 유지하면서도 매우 빠르고 정확한 에이전트 경험을 제공하는 것이 기술적 결론입니다. ### 컨텍스트 엔진의 구조와 데이터 처리 * **커넥터와 정규화**: 수많은 서드파티 앱의 API 제약과 권한 체계(ACL)를 처리하는 맞춤형 크롤러를 통해 데이터를 수집하고, 이를 마크다운 형식으로 정규화하여 관리합니다. * **멀티모달 콘텐츠 이해**: 단순 텍스트 추출을 넘어 이미지(CLIP 및 멀티모달 모델), 오디오(전사), 비디오(장면 추출 및 이해)에 대한 심층 분석을 수행하여 인덱싱합니다. * **지식 그래프 모델링**: 문서, 회의, 인물 간의 관계를 그래프 형태로 연결하여 단순 검색 이상의 맥락 정보를 생성하며, 이를 통해 앱 간 경계를 넘나드는 지능형 정보를 제공합니다. * **하이브리드 검색**: 어휘 검색을 위한 BM25와 의미론적 검색을 위한 밀집 벡터(Dense Vector) 저장소를 동시에 사용하여 검색 품질을 극대화하고, 최종 결과에 대해 개인화된 랭킹을 적용합니다. ### 인덱스 기반 검색(Indexed Retrieval)의 채택 이유 * **페더레이션 방식과의 차이**: 실시간으로 외부 API를 호출하는 페더레이션 방식은 구현이 쉽고 데이터가 신선하지만, 속도가 느리고 회사 전체 공유 데이터에 접근하기 어렵다는 단점이 있습니다. * **성능과 실험 가능성**: 인덱스 기반 방식은 데이터를 미리 처리해두기 때문에 응답 속도가 매우 빠르며, 오프라인 환경에서 다양한 랭킹 실험을 통해 검색 정확도(Recall)를 지속적으로 개선할 수 있습니다. * **구축 비용 감수**: 높은 저장 비용과 맞춤형 커넥터 개발의 복잡성에도 불구하고, 풍부한 데이터 세트 구축과 정교한 검색 품질을 위해 인덱스 기반 접근법을 선택했습니다. ### MCP의 한계 극복과 에이전트 최적화 * **컨텍스트 부패 방지**: MCP 도구 정의가 컨텍스트 창(Context Window)을 과도하게 점유하여 발생하는 성능 저하 문제를 해결하기 위해 약 10만 토큰 수준으로 컨텍스트를 제한하고 관리합니다. * **응답 속도 개선**: 일반적인 MCP 에이전트가 여러 도구를 호출할 때 발생하는 지연 시간(최대 45초)을 줄이기 위해, 원본 인덱스에 직접 접근하여 수 초 내에 결과를 반환하도록 설계했습니다. * **슈퍼 툴(Super Tool) 개념**: 개별 앱마다 도구를 정의하는 대신, 전체 인덱스를 아우르는 '슈퍼 툴' 인터페이스를 구축하여 모델이 추론해야 할 도구의 개수를 줄이고 효율성을 높였습니다. 기업용 AI 에이전트를 구축할 때는 실시간 API 호출 방식보다는 비용이 들더라도 데이터를 직접 인덱싱하고 지식 그래프화하는 것이 검색 품질과 속도 면에서 유리합니다. 특히 MCP와 같은 최신 프로토콜을 도입할 때는 도구 정의가 컨텍스트 창을 잠식하지 않도록 '슈퍼 툴' 형태의 추상화 계층을 고려하는 것이 실무적으로 권장됩니다.

prompt-optimization모델 컨텍스트 프로토콜RAG멀티모달 AI+4