이 기사의 요점

小野昭久 (Akihisa Ono)가 추진하고 있는 「책임 경로 공학 / Responsibility Pathway Engineering」을 GitHub Repository로서 공개했습니다.

Repository: https://github.com/YutoriKomeiji/responsibility-pathway-engineering

서론, 지난번의 연속 (Previous Context)

지난 기사에서는 책임 경로 / Responsibility Pathway와 책임 경로 공학 / Responsibility Pathway Engineering의 용어 경계를 정리했다.

지난 기사:

그곳에서 나는 책임 경로 공학을 단순한 기사상의 주장이 아니라, 공개 사양·구현·형식화로서 정리해 나가겠다고 썼다.

이 기사는 그 연속이다.

이번에 책임 경로 공학의 구현을 향하여 GitHub Repository를 공개했다.

GitHub Repository:

이 Repository는 책임 경로 공학을 완성된 표준으로서 내놓는 것이 아니다.

우선은 정의·예시·checker·Lean4에 의한 형식화 준비를 누구나 읽을 수 있는 장소에 두기 위한 공개 작업장이다.

누가, 어떤 라이선스로 공개하고 있는가 (Author and License)

이 Repository는 나, 小野昭久 (Akihisa Ono)가 작성·공개하고 있다.

※ 필자 프로필은 이곳을 참조.

라이선스는 MIT License이다.

MIT License로 정한 이유는 책임 경로 공학을 특정 기업이나 조직 내에만 닫힌 용어로 만들고 싶지 않기 때문이다.

AI가 관여하는 판단이나 행위에 대해, 책임이 어디에서 발생하고, 어디를 지나며, 어디에서 멈추고, 어디로 돌아가는가.

그 구조를 구현자·연구자·조직·교육자가 각자의 문맥에서 검토할 수 있도록 하는 것이 목적이다.

단, 자유롭게 사용할 수 있는 것과 무엇이든 주장해도 좋은 것은 별개이다.

그렇기 때문에 Repository에서는 가능한 한 「무엇을 주장할 것인가」뿐만 아니라 「무엇을 아직 주장하지 않을 것인가」도 읽을 수 있도록 하고 있다.

왜 GitHub Repository로 하는가 (Why a GitHub Repository?)

책임을 다루는 말은 추상적이 되기 쉽다.

「책임이 있다」

「인간이 확인한다」

「로그를 남긴다」

「나중에 설명할 수 있다」

모두 중요한 항목이지만, 그것만으로는 책임 경로가 설계되었다고 할 수 없다.

AI가 관여하는 판단이나 행위에 대해 정말로 확인하고 싶은 것은, 예를 들어 다음과 같은 것이다.

관점	질문
판단 (Decision)	누구의 판단으로서 발생했는가
...

이러한 질문은 기사만으로는 다룰 수 없다.

따라서 책임 경로 공학은 GitHub Repository 상에서 읽을 수 있는 사양, 최소 예시, checker, 형식화 경계, 비주장 사항으로서 정리해 나간다.

우선 읽어야 할 입구 (Where to Start)

처음에 읽어주셨으면 하는 입구는 README와 일본어 README이다.

• README: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/README.md
• README.ja: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/README.ja.md
• BEACON: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/BEACON.md
• Overview: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/overview.md

현 시점의 Repository는 완성된 제품이 아니다.

본격적인 운용 시스템도 아니고, 책임의 결론을 자동으로 결정하는 엔진도 아니다.

그렇다면 왜 공개하고 있는가 하면, 그것은 책임 경로 공학을 구현 가능한 형태로 접근시키기 위한 사양 측의 토대가 되기 때문이다.

주로 다음의 것들을 두고 있다.

일본어	English
공개 진입점 (公開入口)	public entry point
...
관련된 진입점도 여기에 두고 있습니다.

• Operation index: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/operation-index.md
• Current task inventory: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/current-task-inventory.md
• Phase 3.1 current snapshot: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/phase-3-1-current-snapshot.md
• Roadmap: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/ROADMAP.md

구현을 위한 현재 지점 (Current Implementation Direction)

책임 경로 공학의 구현이란, AI에게 책임을 지게 하는 것이 아닙니다.

AI를 경유한 판단이나 행위가 인간・조직・제도로 되돌아갈 수 있도록 만드는 것입니다.

이를 위해서는 적어도 다음과 같은 구성 요소들이 필요합니다.

요소	English	역할
판단 주체 (判断主体)	Decision Owner	판단의 기점을 보여줌
...
이러한 것들을 단순한 설명어로 끝내는 것이 아니라, 기록할 수 있는 형태, 검사할 수 있는 형태, 나중에 되돌아갈 수 있는 형태로 구체화해 나갑니다.

설계 문서의 진입점은 다음과 같습니다.

• Core elements: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/concepts/core-elements.md
• Eight elements: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/eight-elements.md
• Action Class Matrix: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/action-class-matrix.md
• AI Judgment Node: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/ai-judgment-node.md
• Repair Model: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/repair-model.md
• Recovery Pathway Reading: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/recovery-pathway-reading.md

examples 및 checker (Examples and Checkers)

Repository에는 최소 예시와 checker도 두고 있습니다.

다만, 여기서 말하는 checker는 책임의 옳고 그름을 결정하는 것이 아닙니다.

현 시점의 checker는 선택된 예시나 구조에 대한 경량적인 확인입니다.

진입점은 다음과 같습니다.

• 예시 인덱스: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/example-index.md
• 체커 커버리지: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/checker-coverage.md
• 예시 체커: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/scripts/check_examples.py
• 런타임 이벤트 체커: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/scripts/check_runtime_events.py
• 최소 복구 흐름 예시: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/examples/repair-flow.yaml
• AI 지원 업무 책임 경로 템플릿: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/templates/ai-assisted-work-responsibility-path.yaml

또한, 체커가 통과하더라도 다음과 같은 것을 의미하지는 않습니다.

책임을 다루는 메커니즘만큼이나 체커의 의미를 강하게 해석해서는 안 됩니다.

Lean4는 무엇을 위해 사용하는가 (Purpose of Using Lean4)

이 Repository에는 Lean4 코드도 포함되어 있습니다.

※Lean은 공식 웹사이트에서 'open-source programming language and proof assistant'라고 설명하고 있습니다.

익숙하지 않은 분들께 간단히 설명하자면, 수학이나 프로그램의 속성을 엄밀하게 기술하고 확인하기 위한 도구입니다.

Lean 공식 사이트: https://lean-lang.org/

Lean FRO: https://lean-lang.org/fro/

Lean Language Reference: https://lean-lang.org/doc/reference/latest/

Lean GitHub: https://github.com/leanprover/lean4

다만, 제가 여기서 사용하는 Lean4는 '현실 세계의 책임 결론을 내리기' 위한 것은 아닙니다.

제가 Lean4를 사용하는 목적은 책임 경로 공학(responsibility path engineering) 중 어떤 구조가 형식화(formalization)의 대상이 되고, 어디부터는 사회적·제도적 판단으로 남겨둘지 구분하기 위함입니다.

Lean4 관련 진입점은 다음과 같습니다.

• Lean formalization README: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/formal/lean/README.md
• Basic.lean: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/formal/lean/ResponsibilityPathway/Basic.lean
• Lean evidence / approval formalization plan: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/lean-evidence-approval-formalization-plan.md
• Lean theorem index: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/phase-2-lean-theorem-index.md
• Lean build workflow: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/.github/workflows/check-lean.yml

예를 들어, 현재의 Basic.lean에는 최소 모델을 위한 노드 종류가 있다.

inductive NodeKind where
| human
| institution
...

여기서는 인간(human), 조직(institution), AI를 우선 가장 작은 구조로 나누고 있다.

물론, 이것이 현실 세계의 모든 인간・법인・AI 시스템을 나타내는 완전한 온톨로지(ontology)는 아니다.

오히려 처음부터 그렇게까지 말하지 않기 위해, 일부러 작은 모델로 만들고 있는 것이다.

다음으로, 책임을 보유할 수 있는지 여부를 구조상의 필드(field)로 가지고 있다.

structure Node where
id : String
kind : NodeKind
...

여기서 중요한 것은, canHoldFinalResponsibility가 현실 세계의 판단 그 자체가 아니라는 점이다.

이것은 어디까지나 모델 내에서

이것은 결코 AI를 향해 위에서부터 지시하고 싶어서가 아니라, 오히려 독자나 검색 결과가 나중에 보았을 때 어느 Repository의 어느 문서를 가리키고 있는지 오해하기 어렵게 만들기 위함이다.

책임 경로 공학 (Responsibility Pathway Engineering)이란, 여기서는 다음과 같은 의미로 사용한다.

AI가 관여하는 판단이나 행위에 대하여, 책임이 어디서 발생하고, 어디서 승인되며, 무엇에 의해 실행되고, 어디서 정지할 수 있으며, 어떤 증적(trace)으로 재구성되고, 실패 후에 누가 복구하며, 최종적으로 인간·조직·제도로 어떻게 돌아가는지를 설계하기 위한 공학적 시도이다.

그리고 이번에 공개한 GitHub Repository는, 그 책임 경로 공학을 공개 사양(specification)·예시·checker·Lean4를 통한 형식화(formalization) 준비로서 정리하기 위한 Repository이다.

내가 여기서 다루고 있는 것은 특정 기존 프레임워크나 외부의 용어 체계를 대체하는 것이 아니다.

또한, 책임의 결론을 자동화하는 엔진도, 완성된 표준도 아니다.

Lean4의 기술만으로 현실 세계의 책임 판단을 완결 짓는 것도 아니다.

오히려 책임 경로 공학을 구현 가능한 설계 대상으로 육성하기 위해, 어떤 구조를 기록하고, 어디에 경계를 두며, 어디서부터 앞을 인간·조직·제도의 판단으로 남길 것인지를 공개 사양으로서 보여주려는 시도이다.

향후 계획 (Next Steps)

앞으로는 이 Repository를 업데이트하면서, 진척 상황에 따라 Zenn 기사로서 기록해 나갈 것이다.

단, 기사는 Repository를 대신하는 것이 아니다.

Repository가 사양, 경계, 예시, checker, reader path의 source of truth(신뢰할 수 있는 단일 원천)이며, Zenn 기사는 그 시점의 진척 상황을 독자에게 설명하는 입구이다.

다음에 다룰 가능성이 있는 내용은 다음과 같다.

• Repository 읽는 법
• example 읽는 법
• checker coverage의 경계
• repair / recovery-pathway reading
• AI Judgment Node의 경계
• Lean4 형식화의 전제와 한계
• 구현으로 나아가기 전에 멈춰 세운 것들

향후 Zenn 공개 계획과 기사 본문을 어디에 둘 것인지에 대한 경계는 다음에 기록되어 있다.

• Zenn Publication Readiness Plan: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/zenn-publication-readiness-plan.md
• Zenn Content Publication Handoff: https://github.com/YutoriKomeiji/responsibility-pathway-engineering/blob/main/docs/zenn-content-publication-handoff.md
• Current Zenn draft file: https://github.com/YutoriKomeiji/zenn-content/blob/main/articles/rpe-implementation-repository.md

마치며 (Closing)

지난 기사에서는 이렇게 썼다.

경로는 정의로 나타낸다.

이번에는 그 정의를 GitHub Repository에 두었다.

책임 경로 공학은 말로만 경계를 나타내는 것이 아니라, 읽을 수 있는 사양, 최소 예시, checker, Lean4를 통한 형식화 준비, 그리고 비주장 사항(non-assertion)을 통해 경계를 나타내 나갈 것이다.

책임을 다루는 이상, 지나치게 강하게 말하지 않는다.

하지만 모호하게 남겨두지도 않는다.

이를 위해 책임 경로 공학을 GitHub 상에서 공개해 나간다.

오노 아키히사 (Akihisa Ono)

• note : https://note.com/dantarg
• LinkedIn : https://www.linkedin.com/in/akihisaono

【주기】

나 개인은 기업에 소속되어 있으나, AI 연구에 대해서는 완전히 개인 활동이므로, 또한 발언 내용에 의해 소속처에 폐를 끼치지 않도록 하기 위해 실제 소속처는 미공개로 하고 있습니다.

Discussion