Search dashboard
수집된 논문, Reading 큐, PDF 유무, worklist를 한 화면에서 확인하고 다음 단계로 보냅니다.
기존 연구 흐름에서는 논문을 찾고, 읽고, 재현하고, 결과를 비교하고, 글을 쓰는 과정이 서로 다른 도구와 파일에 흩어졌습니다. 논문을 읽어도 곧바로 재현 계획으로 이어지기 어렵고, 재현 실패나 성능 차이는 다음 연구의 자산으로 남기 어렵습니다.
논문 검색 결과는 목록으로 남지만, 이후 리딩·재현·결과 비교에 필요한 문맥은 별도로 다시 구성해야 했습니다.
논문에서 찾은 방법, 한계, 실험 조건이 곧바로 reproduction checklist나 실험 계획으로 이어지지 않았습니다.
재현 실패, 성능 차이, 후속 가설이 문서와 로그 사이에 흩어져 다음 연구의 시작점으로 축적되지 않았습니다.
ARES는 ARIS의 agent 실행 경험에서 출발했지만, 런타임 모델은 다르게 잡았습니다. ARES에서 agent는 대화를 이어가는 존재라기보다, 논문·리딩 세션·실험 결과·인사이트 같은 연구 자산을 다음 단계로 넘기는 역할을 맡습니다.
프로젝트별 논문 라이브러리, Reading 세션, agent run 메타데이터를 하나의 흐름 안에서 다룹니다. 검색 결과는 곧바로 읽을 수 있는 paper asset이 되고, Reading 세션은 이후 Lab과 Insight 단계의 근거가 됩니다.
ARES는 장기적으로 6단계 플랫폼이지만, 처음부터 모든 단계를 완성하려 하지 않았습니다. 현재 가장 실제적인 경로는 Search와 Reading입니다. Scout 검색, 저장된 paper worklist, PDF viewer, parse/summarize/chat/notes/assets 흐름이 이 축에 놓입니다.
수집된 논문, Reading 큐, PDF 유무, worklist를 한 화면에서 확인하고 다음 단계로 보냅니다.
저장된 논문을 상태별로 필터링하고, PDF가 있는 항목을 Reader workspace로 엽니다.
PDF, outline, notes, chat, asset tab이 같은 Reading session 안에서 함께 움직입니다.
Research, Result, Insight, Writing은 제품 방향과 handoff를 보여주는 scaffold로 먼저 연결했습니다.
Reading v1은 PDF URL을 가진 논문을 기준으로 동작합니다. ARES는 PDF를 열고, 텍스트 레이어를 기반으로 parse/summarize/chat 기능을 제공하지만, 이미지뿐인 scanned PDF의 OCR은 현재 범위에 넣지 않았습니다.
역할 · 논문 원문을 Reading workspace 안에서 직접 열어 본문과 작업 패널을 함께 보여줍니다.
경계 · 텍스트 레이어가 없는 스캔 문서는 열 수 있어도 요약과 인용 기반 chat에는 제한이 있습니다.
역할 · PDF에서 추출 가능한 텍스트를 섹션과 요약 카드로 바꿔 이후 작업의 근거를 만듭니다.
경계 · OCR은 별도 stage로 남겨 두고, 현재는 실패 사유를 명시하는 쪽을 우선했습니다.
역할 · Reading 중 선택한 문맥과 논문 상태를 질문에 연결합니다.
경계 · 표시된 selection과 backend prompt가 같은 텍스트를 갖는지 검증하는 것이 핵심이었습니다.
ARES 상세 페이지는 제품 비전을 보여주되, 실제 구현 상태를 과장하지 않습니다. Search와 Reading은 backend/UI 경로가 있는 실제 MVP이고, Lab 이후 단계는 연구 워크플로우의 방향과 handoff 구조를 보여주는 초기 표면입니다.
논문 검색, 저장, Reading 큐, worklist와 fallback 데이터 경로가 연결되어 있습니다.
PDF view, parse, summarize, chat, notes, assets가 Reading session에 묶여 있습니다.
Research, Result, Insight, Writing은 현재 제품 방향과 stage handoff를 보여주는 표면입니다.
ARES 개발에서 가장 조심한 경계.
다음 연구 도구로 가져갈 판단.