이 워크플로우(workflow)를 구축하면서 나를 놀라게 했던 점은, 처음에 나는 파이프라인이 완성되었다고 생각했다는 것입니다: 목표(Goal)로부터 → 분해(Decompose) → 연구(Research) → 사양(Specification) → 구현(Implementation) 단계로 이어지는 과정 말입니다. 그것은 문제를 관련 블록으로 성공적으로 나누었고, 각 블록에 대한 연구를 찾아냈으며, 상세한 구현 사양을 생성했습니다. 하지만 그것은 아직 올바르지 않다는 것을 알아차렸습니다. 문제는 LLM이 종종 자신이 발견한 모든 관련 방법을 구현하려고 시도했다는 점입니다. 예를 들어, 만약 다섯 개의 논문이 다섯 가지 서로 다른 접근 방식을 설명한다면, 생성된 구현은 원래의 엔지니어링 목표가 단 하나만을 요구할 때조차 때때로 그들 모두를 결합하곤 했습니다. 또 다른 경우에는 다음과 같은 것들을 구분할 수 없었기 때문에 중복된 입력을 수용하거나 불필요한 추상화(abstractions)를 도입하기도 했습니다: * 유용한 컨텍스트 (useful context) * 흥미로운 대안들 (interesting alternatives) * 그리고 실제 설계 결정 (actual design decisions). 그리고 이로 인해 나는 연구가 구현을 안내(guide)해야 하지만, 연구 그 자체가 구현이 되어서는 안 된다는 것을 깨달았습니다. 누군가는 어떤 접근 방식을 취할지, 어떤 방법들을 제외해야 하는지, 우리가 어떤 가정을 하고 있는지, 그리고 정확히 무엇을 구현해야 하는지를 결정해야 합니다. 그것이 바로 내가 워크플로우에 필수적인 편집 단계(editing stage)를 추가한 이유입니다. 그래서 연구 후에 즉시 코드를 생성하는 대신, 워크플로우가 멈춥니다. 이는 추출된 연구 내용을 검토(reviewable)할 수 있음을 의미합니다. 이는 구현 결정(implementation decisions)을 개선(refinable)할 수 있게 만들며, 그 시점에 최종 사양(final specification)이 생성될 수 있습니다. 목표는 프로세스를 늦추는 것이 아닙니다. 하지만 모델이 발견한 모든 가능성이 아니라, 생성된 구현이 실제로 원래의 엔지니어링 계획을 반영하도록 보장하는 것입니다. 이제 나는 AI 출력물에 게이트(gating)를 두는 것이 단순히 선택 사항이 아니라, 신뢰할 수 있는 엔지니어링 워크플로우를 구축하는 데 있어 가장 중요한 부분 중 하나일 수도 있다고 생각하기 시작했습니다. 나는 딥러닝(deep-learning) 시스템을 분해, 연구, 사양 정의 및 구현하기 위한 더 광범위한 MCP 시스템의 일부로 이것을 구축하고 있습니다.

만약 이 시스템에 대해 논의하거나, 테스트하거나, 개발에 기여하는 데 관심이 있는 분이 있다면, 토론(discussion)에 GitHub 저장소(repository) 링크가 연결되어 있습니다. 또한 다른 분들은 검색된 연구(retrieved research)를 구체적인 구현 결정(implementation decisions)으로 어떻게 전환하는지에 대해서도 듣고 싶습니다. /u/hypergraphr가 r/MachineLearning에 게시함 [link] [comments]