jhogyu
20c5235e68
- Created new files for Stage 1 evaluation and revision strategy based on GPT and Claude recommendations. - Added detailed revision plans addressing runtime issues in LES2 and optimizing workflows for Stage 2. - Updated existing Stage 1 to Stage 2 transition prompts with additional search results and completion indicators. - Enhanced clarity and structure in the documentation for better usability and understanding.
225 lines
12 KiB
Plaintext
225 lines
12 KiB
Plaintext
|
|
Stage 2 개정 작업 Plan
|
|
|
|
- stage 1 정합성 체크 / 개정 필요 식별 / 최소한도 개정 전략서 생성
|
|
-> stage 2 작업 전체 흐름 파악 -> 사용 정보를 최대한 구체적으로 식별 (field 별로)
|
|
-> 현행 stage 2 작업에 사용될 정보 field를 개정 stage 1 작업명세서와 BO/Fact_Ledger/3-signals (+추가 생성 블록)과 대조하여 일치/기존만존재/신규에만존재 등으로 분리 식별
|
|
-> 현행 stage 2 작업의 궁극적 목표를 위해 필요한 DAG workflow 식별
|
|
-> 개정 stage 1 작업 결과물을 stage 2 작업 명세로 효과적으로 전달하는 방법 식별
|
|
|
|
2. 6/29 월요일
|
|
- stage 1 개정
|
|
-> stage 1 실행 및 결과 보존
|
|
-> stage 2 개정 전략서 확정
|
|
-> stage 2 개정
|
|
-> stage 2 실행 및 결과 평가
|
|
|
|
3. 6/30 화요일
|
|
- stage 2 결과 평가 by 성용배
|
|
-> 오류 식별
|
|
-> 원인 식별 / 개정 방안 도출(minimal correction - Schema / prompt / module / DB 문서 등)
|
|
-> 개정 전략서 생성
|
|
-> 개정 -> 실행 -> 평가
|
|
|
|
- stage 1 & 2만 가지고 성용배가 몇 개 사건 더 평가
|
|
- 사건: 변시기출/법전협모의/사법연수원교재
|
|
- 비교대상: GPT-Pro w/ Project / Claude Project / Gemini NoteBookLM
|
|
- 평가서 template 미리 작성
|
|
-> 기준:
|
|
1. 청구권 식별
|
|
2. 청구취지 정확성
|
|
3. 청구원인 정확성
|
|
4. 요건사실에 따른 항변/재반박 품질과 정확성
|
|
5. 소장의 청구권 서술을 뒷받침할 가장 강력한 과거 판례 식별 품질.
|
|
|
|
4. 7/1 수요일
|
|
- stage 3/4/5 개정 전략서 생성
|
|
-> 원고대리 민사소송 사건 종류 70개 확장 결정
|
|
-> 사건 확장을 위한 민사소송용 일반성 규칙 설정
|
|
-> "청구취지작성규칙" "요건사실론문서" 생성 workflow 확정
|
|
-> 판결문 수집 규칙 정해서 아르바이트 구성
|
|
- 작업예상: 사건 1건당 최소 0.2일 ~ 최대 3일
|
|
- 1명 1일 수집 판결: 대략 2-3건
|
|
- 사건종류 70개 -> 분리/병합 시 90개 예상 -> 1사건당 평균 1일 -> 총 90일 필요
|
|
-> pm=백지민, 휘하 9명 -> 총10명, 1명당 1일평균 2건, 총 5일 소요 (1주일 기준으로 완성하기)
|
|
-> 아르바이트 금액: 1일 5만원 산정 -> 하루 총 50만원 -> 5일 총 250만원 + 10만원(백지민)
|
|
|
|
|
|
======================================================================================
|
|
|
|
[추가작업]
|
|
민사소송 법원(판사)용 판결문 작성 에이전트 신설 준비
|
|
형사소송 피고 에이전트 신설 준비
|
|
형사소송 법원(판사)용 판결문 작성 에이전트 신설 준비
|
|
민사소송 원고 에이전트 시스템 프롬프트: 김영배 문서내용 구조화 반영 + make it lean + 좀 더 구조화
|
|
요건사실론 문서 작성 worklfow 작동 여부 테스트
|
|
-> 작업 내용:
|
|
- 참고문헌 문서를 조각내서 모으고, OCR 처리하는 작업을 생략
|
|
- source를 핵심 도서의 page 번호(pdf page & book page)만 제공
|
|
-> 문서 생성:
|
|
- [Codex / Gemini NoteBookLM / Claude] 동시 생성
|
|
-> [GPT Pro / Gemini DT / Claude Research / Perplexity Compute / Kimi Agent / GenSpark] 평가
|
|
-> [Codex / NoteBookLM / Claude] 재생성
|
|
-> Codex 앙상블 최종 생성
|
|
Weaviate DB 구성 및 vector search 개정 작업
|
|
고급 판례 검색 및 판례 연구를 위한 GraphDB 구성 개요 연구
|
|
|
|
======================================================================================
|
|
|
|
======================================================================================
|
|
|
|
|
|
2. <IR_개정용_추가자료>의 문서들과 웹사이트들이 제시하는 내용을 분석하여 아래의 순서로 보고서를 작성한다:
|
|
1) 현 시점에서 AI를 사용하여 서비스를 제공하는 스타트업들이 경쟁력을 가지고 살아남을 수 있는 사업 방향 정리
|
|
2) 왜 Vertical AI Agent를 개발하는 것이 스타트업이나 다른 회사들에게 확실한 경쟁력 우위를 제공하는 사업 기회가 되는지 정리
|
|
3) 추가적인 웹사이트 검색을 통해서 1),2) 내용을 보완한다.
|
|
4) 1),2),3) 작업 내용에 근거하여 Eroom AI Partners가 제공하는 Vertical Legal AI Agent가 사업 모형으로서 경쟁력을 가질 수 밖에 없는 이유를 정리
|
|
|
|
┌───────────────────────────────────────┐
|
|
│ │
|
|
│ Contents to be Dealt │
|
|
│ │
|
|
└───────────────────────────────────────┘
|
|
|
|
|
|
# Foundation LLM을 API로 사용하거나, OpenSource LLM을 직접 서빙해야하는 AI 스타트업이 경쟁력을 가지고 살아남는 사업 방향
|
|
1. 구축하지 말아야 할 서비스 계층
|
|
- AI Wrapper와 범용 Copilot 형태 서비스는 살아남을 수 없다.
|
|
|
|
2. 생존하는 AI 서비스는 "도구"가 아니라 "업무 시스템"이다.
|
|
<살아남을_AI_스타트업의_사업_방향>
|
|
- 고객 업무의 한 기능이 아니라 업무 흐름 전체를 소유한다.
|
|
- 단순 요약이나 초안이 아니라 실제 산출물과 의사결정까지 연결한다.
|
|
- 범용 모델 성능보다 도메인별 정답 기준, 실패 기준, 승인 기준을 시스템화한다.
|
|
- 고객의 사용 과정에서 데이터와 피드백이 누적되는 구조를 만든다.
|
|
- human-in-the-loop를 비용이 아니라 신뢰, 책임, 학습 루프의 핵심으로 설계한다.
|
|
- 단일 제품 웨지로 시작하되, 인접 워크플로우와 데이터 레이어를 흡수하여 vertical platform으로 확장한다.
|
|
</살아남을_AI_스타트업의_사업_방향>
|
|
|
|
3. AI 시대의 인간 전문성을 AI 서비스 혹은 에이전트의 검증 레이어로 활용해야 한다.
|
|
|
|
# Vertical AI Agent가 경쟁우위를 가질 수 밖에 없는 이유
|
|
1. Vertical AI는 "last mile problem"을 해결한다
|
|
- 예시: 범용 생성형 AI는 법률 질문에 그럴듯한 답을 줄 수 있지만, 법조인이 실제 사용할 수 있는 수준의 일관성, 출처, 절차, 재현 가능성, 책임 구조를 제공하지 못한다.
|
|
- `Domain-native LLM application.pdf`는 의료 사전심사 사례를 통해 같은 문제를 보여준다. 좋은 모델만으로는 충분하지 않고, 도메인 인사이트와 파이프라인을 결합하는 시스템이 더 중요하다. Anterior 사례에서는 기본 성능 95.73%에서 특정 고객과의 8주 반복을 통해 99.24%까지 성능을 개선했다. 핵심은 domain expert가 성능 지표, failure mode, 개선 제안을 만들고, 제품이 생산 데이터로부터 고객 워크플로우를 점점 더 잘 이해하게 되는 적응형 도메인 지능 엔진이다.
|
|
|
|
- 법률에서 이 last mile은 더 강하다. 법률 문서의 품질은 단순 문장력이나 법률 지식 퀴즈가 아니라 사실관계 구조화, 청구권 구성, 요건사실 충족, 항변 예측, 판례 근거, 금액 계산, 소송 전략, 법원 제출 형식, 변호사 책임까지 포함한다. 이것은 prompt 하나로 해결할 수 없고, 업무 시스템으로 구현해야 한다.
|
|
|
|
2. Vertical AI Agent는 소프트웨어 예산이 아니라 노동 예산을 흡수한다.
|
|
- Vertical AI의 경제적 강점은 단순 SaaS보다 크다. Vertical SaaS가 업무를 기록하고 관리했다면, Vertical AI Agent는 업무를 수행하고 검증 가능한 산출물을 만든다. 이 경우 고객이 지불하는 기준은 "소프트웨어 좌석값"이 아니라 "기존 인력 또는 외주 비용을 얼마나 대체하거나 증폭하는가"가 된다.
|
|
|
|
|
|
3. Vertical AI Agent의 해자는 독점 데이터보다 더 넓다.
|
|
- 지정 자료들은 반복적으로 data moat를 강조하지만, Eroom이 구축해야 할 해자는 단순 데이터 양이 아니다. 진짜 해자는 다음의 결합이다.
|
|
<진정한_해자_요소>
|
|
- 사건 및 증거 문서에서 추출되는 구조화 사실 데이터
|
|
- 청구권, 항변, 재반박, 판례 연결 방식
|
|
- 변호사가 어떤 출력물을 수정했고 왜 수정했는지에 관한 판단 데이터
|
|
- 잘못된 계산, 누락된 요건사실, 부정확한 판례 인용 등 failure mode taxonomy
|
|
- 법률 문서별 release gate와 checklist
|
|
- 법조인의 작업 순서를 반영한 workflow memory
|
|
- 고객별 선호, 사건 유형별 전략, 법원 제출 형식에 대한 운영 지식
|
|
</진정한_해자_요소>
|
|
이 데이터는 공개 웹에 존재하지 않고, 모델 회사가 외부에서 수집하기 어렵다. 고객 업무 안에서 에이전트가 반복 실행되고, 법조인이 검토하고, 실패가 기록될 때만 생긴다. 따라서 Eroom의 초기 고객 확보는 단순 매출 확보가 아니라 legal agent learning loop 확보라는 전략적 의미를 갖는다.
|
|
|
|
4. Vertical AI Agent는 모델 독립성과 비용 최적화를 가능하게 한다.
|
|
- Vertical application company가 특정 모델 회사에 종속될 필요가 없다. 각 sub-task에 가장 적합한 모델을 선택하고, 모델 업그레이드 때마다 eval을 다시 돌리고, 고객 edge case에 맞춰 prompt와 workflow를 조정하는 운영 레이어가 바로 제품 가치가 된다.
|
|
|
|
5. 고책임 산업에서는 governance가 제품 자체다.
|
|
- 2026년 5월 arXiv 논문 `Agentic AI in Industry`는 산업 현장에서 agentic AI의 production 통합을 막는 핵심 장애로 output verification mechanism 부재를 지적한다. 많은 회사가 실험 단계에서는 더 높은 capability를 보이지만, 충분한 검증 메커니즘이 없어 production workflow에 통합하지 못하고 HITL만이 유일하게 신뢰되는 검증 방식으로 남는다.
|
|
|
|
- 2025년 12월 arXiv의 `A Practical Guide for Production-Grade Agentic AI Workflows`도 agentic workflow를 단일 prompt가 아니라 multi-agent, tool integration, orchestration logic, external system interaction으로 구성된 dynamic pipeline으로 설명한다. 또한 reliable, observable, maintainable, safety/governance aligned 시스템 설계가 핵심 과제라고 정리한다.
|
|
|
|
- 법률은 이 명제가 가장 강하게 적용되는 산업이다. 법률 AI의 구매자는 "무엇을 만들 수 있는가"보다 "그 결과를 믿고 제출할 수 있는가", "출처를 추적할 수 있는가", "잘못되면 누가 책임지는가", "변호사가 어디서 승인했는가"를 묻는다. Eroom의 제품 경쟁력은 UI나 답변 품질만으로 평가되지 않고, audit log, source grounding, release gate, reviewer agent, HITL 승인, data isolation을 얼마나 시스템화했는지로 결정된다.
|
|
|
|
========================================================================
|
|
|
|
|
|
아래 제시한 마크다운 문서(<source_docs>)들의 해당 section들을 꼼꼼히 읽고 분석한다.
|
|
<source_docs>
|
|
<Eroom_AI_경쟁력분석_GPT.md>
|
|
- 0. 결론 요약
|
|
- 1. 현 시점 AI 스타트업이 경쟁력을 가지고 살아남는 사업 방향
|
|
- 2. Vertical AI Agent가 확실한 경쟁 우위가 되는 이유
|
|
- 3. 추가 웹 검색으로 보완한 시장 신호
|
|
|
|
<Eroom_AI_경쟁력분석_Claude.md>
|
|
- 0. 핵심 요약 (Executive Summary)
|
|
- 1. AI 시대, 스타트업이 살아남는 사업 방향
|
|
- 2. 왜 Vertical AI Agent인가 — 확실한 경쟁우위의 원천
|
|
|
|
<Eroom_AI_경쟁력분석_Kimi.md>
|
|
- Executive Summary
|
|
- 1. AI 시대 스타트업의 생존 전략: Yellow Brick Road를 피하고 Rest of Oz로
|
|
- 2. Vertical AI Agent가 유일한 승자의 길인 이유
|
|
|
|
<Eroom_AI_경쟁력분석_Gemini.md>
|
|
- 1. 현 시점, AI 스타트업의 생존 및 경쟁력 확보 방향
|
|
- 2. 왜 'Vertical AI Agent'가 확실한 경쟁 우위(Moat)를 제공하는가?
|
|
</source_docs>
|
|
|
|
<source_docs> 문서들의 section들 내용에 기반을 두고 아래에 제시하는 <content_structure>를 뼈대로 삼아 2장 ppt 슬라이드 분량의 글을 작성하라. 구조화된 이미지를 표현해야 할 필요가 있을 때는 ASCII 아트를 사용하라.
|
|
|
|
<content_structure>
|
|
# 제목: AI를 엔진으로 삼아 서비스를 제공하는 스타트업이 나아가야 할 방향
|
|
1. AI 스타트업이 Foundation LLM을 서빙하는 빅테크의 시장 공세에서 생존할 수 있는 사업 방향은?
|
|
2. AI 스타트업이 해자(moat)로 삼을 수 있는 것은?
|
|
3. AI 스타트업이 확실한 경쟁 우위를 가지기 위해서 왜 Vertical AI Agent를 개발해야 하는가?
|
|
</content_structure>
|
|
|
|
작성한 글을 <AI_스타트업_생존전략.md>로 생성하라.
|
|
|
|
|
|
========================================================================
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|