이종 모델 교차 운영은 하나의 워크플로우 안에서 역할별로 서로 다른 모델을 배치하는 패턴이다.
비싼 프런티어 모델은 판단이 중요한 일에만 쓰고 대량 작업은 저렴한 모델에 맡겨 비용과 속도를 함께 잡는다.
이 절의 Sol(max)과 Luna(max)은 별도 모델이 아니라 gpt-6-sol과 gpt-6-luna의 max effort 설정이다.

Vận hành chéo đa mô hình là mẫu hình bố trí các mô hình khác nhau theo vai trò trong cùng một quy trình.
Mô hình frontier đắt tiền chỉ dùng cho việc cần phán đoán quan trọng, còn khối lượng công việc lớn giao cho mô hình rẻ để vừa tiết kiệm chi phí vừa tăng tốc độ.
Sol (max) và Luna (max) trong mục này không phải mô hình riêng mà là thiết lập max effort của gpt-6-sol và gpt-6-luna.

역할 분담은 비교안 A와 B에 공통이다.
메인 모델은 Claude Code Opus 5.5 또는 gpt-6-sol이며 코디네이터를 맡아 계획과 리뷰를 담당하고, 나머지 실행 작업은 전부 서브에이전트가 수행하며 서브에는 Muse Spark 1.3 Contributor가 포함된다.
Contributor 입력 단가는 표준 티어의 약 1/12이며 프롬프트 학습 동의가 조건이다.

Phân chia vai trò chung cho phương án so sánh A và B.
Mô hình chính, gồm Claude Code Opus 5.5 hoặc gpt-6-sol, đóng vai trò điều phối viên phụ trách lập kế hoạch và review, còn mọi tác vụ thực thi khác đều do sub-agent đảm nhiệm, bao gồm cả Muse Spark 1.3 Contributor.
Đơn giá đầu vào của Contributor bằng khoảng 1/12 của tier tiêu chuẩn, với điều kiện đồng ý cho học từ prompt.

비교 전제는 다음과 같다.
비교안 A는 Opus 5.5와 Contributor, 비교안 B는 Sol(max)과 Contributor, 기존안 1은 전부 Opus 5.5, 기존안 2는 Sol(max)과 Luna(max)이며, 네 구성 모두 동일한 작업 분할과 서브에이전트 구조를 쓰고 차이는 모델 단가뿐이다.
비용 공식은 월 토큰량에 단가를 곱하고 역할별로 30 대 70 분할을 적용한다.
가정: 월 입력 50M·출력 10M 토큰, 메인 30%·서브 70%.

Tiền đề so sánh như sau.
Phương án so sánh A gồm Opus 5.5 và Contributor, phương án so sánh B gồm Sol (max) và Contributor, cách cũ 1 dùng toàn Opus 5.5, cách cũ 2 gồm Sol (max) và Luna (max); cả bốn cấu hình dùng chung cách chia nhỏ công việc và cấu trúc sub-agent, chỉ khác đơn giá mô hình.
Công thức chi phí lấy lượng token tháng nhân đơn giá và áp dụng phân chia 30/70 theo vai trò.
Giả định: mỗi tháng đầu vào 50M · đầu ra 10M token, mô hình chính 30%, sub-agent 70%.

표 1 가정 리마인더: 월 입력 50M·출력 10M 토큰, 메인 30%·서브 70% 분할이며, Sol(max)과 Luna(max)은 max effort 설정이다.

Nhắc lại giả định của Bảng 1: mỗi tháng đầu vào 50M · đầu ra 10M token, chia mô hình chính 30% · sub-agent 70%; Sol (max) và Luna (max) là thiết lập max effort.

자팀의 월 토큰 사용량과 메인·서브 분할 비율을 이 절의 공식에 대입해 표를 다시 계산한다.
전제 조건은 역할별 토큰 계측이며, 확인 방법은 한 달 청구서와 추정치의 오차 점검이다.

Thay lượng token tháng và tỉ lệ chia chính·sub của nhóm mình vào công thức ở mục này để tính lại bảng.
Điều kiện tiên quyết là đo token theo vai trò, cách kiểm tra là đối chiếu hóa đơn một tháng với ước tính.

서브에이전트에 맡길 수 있는 실행 작업이 많고 대량 토큰을 쓰는 팀일수록 교차 운영이 유리하다.
품질이 중요한 판단은 메인 모델에 남기고 나머지는 과감히 위임하는 것이 이 패턴의 요지다.

Nhóm càng nhiều tác vụ thực thi ủy thác được cho sub-agent và càng dùng nhiều token thì vận hành chéo càng có lợi.
Cốt lõi của mẫu hình này là giữ phán đoán quan trọng ở mô hình chính và mạnh dạn ủy thác phần còn lại.

모놀리식 CI는 어떤 파일을 바꾸든 전체 도메인의 빌드와 테스트를 매번 돌린다.
변경과 무관한 도메인까지 대기하고 과금되므로, 도메인이 늘어날수록 시간과 비용 낭비가 커진다.

CI nguyên khối chạy build và test của mọi domain mỗi lần, dù file bị đổi thuộc domain nào.
Các domain không liên quan cũng phải chờ và bị tính phí, nên càng nhiều domain càng lãng phí thời gian và chi phí.

분리 절차는 다섯 단계다.
먼저 DDD 경계를 기준으로 CI를 나누고, 각 파이프라인에 경로 기반 트리거를 건다.
그 다음 테스트를 도메인별로 스코핑하고, 변경 없는 도메인의 파이프라인은 스킵한다.
마지막으로 의존성 캐시와 빌드 아티팩트를 도메인 간에 공유해 중복 작업을 줄인다.

Quy trình tách gồm năm bước.
Trước hết tách CI theo biên DDD, rồi gắn kích hoạt theo path cho từng pipeline.
Tiếp theo giới hạn phạm vi test theo từng domain, và bỏ qua pipeline của domain không đổi.
Cuối cùng chia sẻ cache phụ thuộc và artifact build giữa các domain để giảm việc trùng lặp.

분리 전에는 작은 수정 하나에도 전체 파이프라인이 돌아가지만, 분리 후에는 변경된 도메인의 파이프라인만 실행된다.
예를 들어 도메인 B의 코드만 바뀌면 B 파이프라인만 돌고 A와 C는 스킵된다.
가정: 전체 CI 30분·3도메인 균등 분담, 분당 과금.
이 경우 단일 도메인 변경 시 실행 시간은 30분에서 10분으로 약 67% 줄고, 분당 비용 기준 절감률도 같은 비율이다.

Trước khi tách, một sửa đổi nhỏ cũng chạy toàn bộ pipeline, còn sau khi tách chỉ pipeline của domain bị đổi mới chạy.
Ví dụ, khi chỉ đổi mã của domain B thì chỉ pipeline B chạy còn A và C được bỏ qua.
Giả định: CI toàn bộ 30 phút · 3 domain chia đều, tính phí theo phút.
Trong trường hợp này, khi đổi một domain, giờ chạy giảm từ 30 phút xuống 10 phút, khoảng 67%, và tỉ lệ giảm theo đơn giá CI cũng tương đương.

분리 CI의 안전망은 도메인 단위 테스트다.
테스트 주도 개발로 도메인마다 빠른 단위 테스트를 갖춰 두면, 해당 도메인 파이프라인만으로도 변경의 영향을 충분히 검증할 수 있다.

Lưới an toàn của CI đã tách là unit test theo domain.
Khi mỗi domain đã có unit test nhanh nhờ phát triển hướng test, chỉ pipeline của domain đó cũng đủ kiểm chứng ảnh hưởng của thay đổi.

전제 조건은 DDD 경계에 맞춘 디렉터리 분리와 도메인별 파이프라인 정의다.
절차는 다음과 같다.
도메인에 새 테스트를 하나 추가하고, 해당 도메인 경로만 건드리는 커밋을 푸시한 뒤, 그 도메인 파이프라인은 통과하고 다른 도메인은 스킵되는지 확인한다.
확인 방법은 CI 실행 기록에서 트리거된 파이프라인 목록과 실행 시간을 대조하는 것이다.

Điều kiện tiên quyết là tách thư mục theo biên DDD và định nghĩa pipeline cho từng domain.
Quy trình như sau.
Thêm một test mới vào domain, đẩy commit chỉ chạm path của domain đó, rồi kiểm tra pipeline của domain ấy đỗ còn các domain khác được bỏ qua.
Cách kiểm tra là đối chiếu danh sách pipeline đã kích hoạt và giờ chạy trong lịch sử CI.

핵심은 도메인별 CI 분리다.
바뀐 도메인만 빌드·테스트하면 CI 실행 시간과 분당 과금 비용이 함께 줄어든다.
DDD 경계가 CI 구조가 되고, TDD 단위 테스트가 그 안전망이 된다.

Điểm cốt lõi là tách CI theo domain.
Chỉ build · test domain bị đổi thì vừa rút ngắn giờ chạy CI vừa giảm chi phí tính theo phút.
Biên DDD trở thành cấu trúc CI, còn unit test của phát triển hướng test là lưới an toàn của nó.

이슈 베이스 개발은 모든 작업을 이슈로 목록화하고 등록하는 것으로 시작한다.
등록된 이슈는 공통 이슈 PR Draft부터 ADR, Spec, 설계, 구현 리뷰까지 이어지는 파이프라인을 통과하고, 통과한 PR들이 모여 머지 트레인에 순서대로 탑재되어 함께 병합된다.

Phát triển dựa trên issue bắt đầu từ việc liệt kê và đăng ký mọi công việc thành issue.
Các issue đã đăng ký đi qua pipeline kéo dài từ nháp PR cho issue chung, ADR, Spec, thiết kế đến review triển khai, và các PR đã vượt qua cổng tập hợp lên merge train theo thứ tự để hợp nhất cùng nhau.

8단계 순서는 다음과 같다.
1단계에서 이슈 목록을 분석하고, 2단계에서 공통 이슈 PR Draft를 생성한다.
3단계부터 5단계까지는 ADR, Spec, 설계를 차례로 작성하며 각 단계마다 자체 리뷰 게이트를 통과해야 한다.
6단계에서는 구현을 진행하고 머지 블로커가 없을 때까지 반복 리뷰하며, 머지 블로커가 아닌 잔여 이슈는 별도로 등록한다.
7단계에서 머지 트레인에 탑재하고, 8단계에서 트레인을 병합한다.

Trình tự 8 bước như sau.
Ở bước 1 phân tích danh sách issue, ở bước 2 tạo nháp PR cho issue chung.
Từ bước 3 đến bước 5 lần lượt viết ADR, Spec và thiết kế, mỗi bước đều phải vượt qua cổng tự review.
Ở bước 6 tiến hành triển khai và review lặp đến khi không còn blocker nào, còn issue còn lại không phải blocker thì đăng ký riêng.
Ở bước 7 lên merge train, và ở bước 8 hợp nhất train.

등록된 잔여 이슈는 다시 이슈 목록으로 회귀하므로, 파이프라인은 목록 분석부터 다시 시작하는 순환 구조다.
탑재와 병합 규칙은 다음과 같다.
통과 순서대로 탑재하고, 머지 블로커인 미해소 리뷰 지적과 CI 실패가 해소될 때까지 탑재를 보류하며, 뒷순위 PR의 선행을 금지한다.

Các issue còn lại đã đăng ký quay về danh sách issue, nên pipeline là cấu trúc vòng lặp bắt đầu lại từ phân tích danh sách.
Quy tắc lên tàu và hợp nhất như sau.
Lên tàu theo thứ tự vượt qua cổng, chờ đến khi blocker gồm ý kiến review chưa xử lý và CI lỗi được xử lý xong, và không cho PR xếp sau vượt lên trước.

기존 PR 플로우는 게이트 없는 단일 PR을 직접 머지하므로 설계 결함이나 리뷰 지적이 머지 후에야 드러난다.
반면 이 구조는 ADR, Spec, 설계 단계마다 자체 리뷰 게이트를 두어 결함을 조기에 걸러내고, 머지 블로커가 아닌 잔여 이슈를 목록으로 회귀시켜 다음 순환에서 처리한다.

Quy trình PR cũ hợp nhất trực tiếp một PR duy nhất không có cổng, nên khiếm khuyết thiết kế hay ý kiến review chỉ lộ ra sau khi hợp nhất.
Ngược lại, cấu trúc này đặt cổng tự review ở từng bước ADR, Spec và thiết kế để lọc sớm khiếm khuyết, và đưa issue còn lại không phải blocker quay về danh sách để xử lý ở vòng lặp tiếp theo.

전제 조건은 이슈 목록과 PR 기반 머지 절차다.
절차는 다음과 같다.
먼저 ADR, Spec, 설계 단계마다 자체 리뷰 게이트를 정의하고 통과 기준을 문서화한다.
다음으로 6단계 리뷰에서 머지 블로커 판정 기준을 정하고, 블로커가 아닌 잔여 이슈를 목록으로 되돌리는 규칙을 만든다.
마지막으로 통과 순서 탑재와 뒷순위 선행 금지 규칙을 적용해 머지 트레인을 운영한다.
확인 방법은 게이트별 산출물 존재 여부와 블로커 해소 전 머지 건수 추적이다.

Điều kiện tiên quyết là danh sách issue và quy trình hợp nhất dựa trên PR.
Quy trình như sau.
Trước hết định nghĩa cổng tự review cho từng bước ADR, Spec, thiết kế và ghi lại tiêu chí vượt qua.
Tiếp theo đặt tiêu chí xác định blocker ở bước review thứ 6, và lập quy tắc đưa issue còn lại không phải blocker quay về danh sách.
Cuối cùng áp dụng quy tắc lên tàu theo thứ tự vượt qua và cấm vượt để vận hành merge train.
Cách kiểm tra là đối chiếu sự tồn tại của sản phẩm từng cổng và theo dõi số vụ hợp nhất trước khi xử lý xong blocker.

게이트별 산출물은 ADR, Spec, 설계 문서이며, 각 산출물은 자체 리뷰를 통과해야 다음 단계로 간다.
머지 조건은 머지 블로커인 미해소 리뷰 지적과 CI 실패가 하나도 없는 것이며, 조건을 만족한 PR만 통과 순서대로 트레인에 탑재되어 함께 병합된다.

Sản phẩm của từng cổng là tài liệu ADR, Spec và thiết kế, mỗi sản phẩm phải vượt qua tự review mới sang bước tiếp theo.
Điều kiện hợp nhất là không còn blocker nào, gồm ý kiến review chưa xử lý và CI lỗi; chỉ các PR thỏa điều kiện mới lên tàu theo thứ tự vượt qua để hợp nhất cùng nhau.

에이전트 스케줄링은 기술 부채 이슈를 무인으로 처리하는 운영 방식이다.
구성은 세 가지다.
스케줄러는 cron 또는 CI 스케줄처럼 정해진 시각에 작업을 시작하는 도구이며 특정 제품에 종속되지 않는다.
원격 개발환경은 EC2 또는 유사한 환경으로, 스펙과 상관없이 에이전트가 작업을 수행하는 장소다.
자동화 스모크 테스트는 작업 결과를 사람이 보지 않고도 검증하는 관문이다.

Lập lịch agent là cách vận hành xử lý các issue nợ kỹ thuật mà không cần người trực.
Cấu phần gồm ba thứ.
Bộ lập lịch là công cụ khởi động công việc vào giờ đã định như cron hay lịch CI, không phụ thuộc vào một sản phẩm cụ thể.
Môi trường phát triển từ xa như EC2 hay môi trường tương tự là nơi agent thực hiện công việc, không phụ thuộc vào cấu hình.
Smoke test tự động là cổng kiểm chứng kết quả công việc mà không cần người xem.

6단계 흐름은 다음과 같다.
1단계에서 기술 부채 이슈를 선정하고, 2단계에서 에이전트에 할당한다.
3단계에서는 에이전트가 원격 개발환경에서 작업을 수행하고, 4단계에서 자동화 스모크 테스트로 결과를 검증한다.
5단계에서 PR을 생성하고, 6단계에서 사람이 리뷰하고 머지한다.
5단계 이후는 3부의 파이프라인과 연결된다.
생성된 PR은 공통 이슈 PR Draft 이후의 게이트와 머지 트레인 규칙을 그대로 따른다.

Luồng 6 bước như sau.
Ở bước 1 chọn issue nợ kỹ thuật, ở bước 2 gán cho agent.
Ở bước 3 agent thực hiện công việc trong môi trường phát triển từ xa, ở bước 4 kiểm chứng kết quả bằng smoke test tự động.
Ở bước 5 tạo PR, và ở bước 6 con người review rồi hợp nhất.
Từ bước 5 trở đi luồng nối với pipeline của phần 3.
PR đã tạo tuân thủ nguyên các cổng sau nháp PR cho issue chung và quy tắc merge train.

실패 처리는 다음과 같다.
스모크 테스트에 실패하면 에이전트가 자동으로 다시 시도하며, 최대 3회까지 반복한다.
가정: 재시도 상한 3회는 운영 편의를 위한 추정치다.
3회 연속 실패하면 해당 작업을 이슈로 재등록하고 사람에게 에스컬레이션한다.

Xử lý lỗi như sau.
Khi smoke test lỗi, agent tự động thử lại, lặp tối đa 3 lần.
Giả định: giới hạn 3 lần thử lại là ước tính để thuận tiện vận hành.
Sau 3 lần lỗi liên tiếp, công việc đó được đăng lại thành issue và leo thang cho con người.

기존 대응 방식은 사람이 주간 단위로 기술 부채를 모아 수동으로 처리하므로, 선정과 검증이 밀리고 야간이나 주말에는 작업이 멈춘다.
반면 스케줄링은 24시간 사이클로 매일 이슈를 선정하고 원격 환경에서 수행한 뒤 스모크로 검증하므로 대기 시간이 사라진다.
가정: 주 5건 처리 기준 주간 대응은 선정부터 머지까지 평균 5일이 걸리고, 자동화는 1일 안에 끝나 대응 속도가 약 5배 빨라진다.

Cách xử lý cũ do con người gom nợ kỹ thuật theo tuần để làm thủ công, nên việc chọn và kiểm chứng bị dồn lại, còn ban đêm hay cuối tuần thì công việc dừng hẳn.
Ngược lại, lập lịch chọn issue mỗi ngày theo chu trình 24h, chạy trong môi trường từ xa rồi kiểm chứng bằng smoke test nên không còn thời gian chờ.
Giả định: với khối lượng 5 vụ mỗi tuần, cách xử lý theo tuần mất trung bình 5 ngày từ khi chọn đến khi hợp nhất, còn tự động hóa xong trong 1 ngày nên tốc độ phản ứng nhanh gấp khoảng 5 lần.

전제 조건은 기술 부채 큐와 스모크 테스트, 그리고 에이전트가 쓸 수 있는 원격 개발환경이다.
절차는 다음과 같다.
먼저 큐에서 우선순위 기준으로 이슈를 선정하는 규칙을 정한다.
다음으로 스케줄러에 24시간 주기 작업을 등록하고, 작업마다 원격 환경 기동과 수행, 스모크 테스트, PR 생성까지 이어지는 명령을 연결한다.
마지막으로 재시도 상한과 재등록 규칙, 에스컬레이션 대상을 정한다.
확인 방법은 스케줄 실행 기록에서 선정 건수와 스모크 통과율, 재등록 건수를 추적하는 것이다.

Điều kiện tiên quyết là hàng đợi nợ kỹ thuật, smoke test và môi trường phát triển từ xa mà agent có thể dùng.
Quy trình như sau.
Trước hết đặt quy tắc chọn issue từ hàng đợi theo mức ưu tiên.
Tiếp theo đăng ký tác vụ chu kỳ 24h vào bộ lập lịch, và nối cho mỗi tác vụ chuỗi lệnh từ khởi động môi trường từ xa, thực hiện, smoke test đến tạo PR.
Cuối cùng đặt giới hạn thử lại, quy tắc đăng lại và đối tượng leo thang.
Cách kiểm tra là theo dõi số vụ đã chọn, tỉ lệ đỗ smoke test và số vụ đăng lại trong lịch sử chạy lịch.

무인 운영 조건은 세 가지다.
정해진 시각에 시작하는 스케줄, 에이전트가 쓰는 원격 개발환경, 결과를 가리는 자동화 스모크 테스트다.
사람 개입 지점은 두 곳이다.
생성된 PR을 리뷰하고 머지하는 지점과, 재시도 상한을 넘긴 이슈를 넘겨받는 에스컬레이션 지점이다.

Điều kiện vận hành không người trực có ba thứ.
Lịch khởi động đúng giờ đã định, môi trường phát triển từ xa cho agent dùng, và smoke test tự động phân định kết quả.
Điểm can thiệp của con người có hai nơi.
Điểm review rồi hợp nhất PR đã tạo, và điểm leo thang tiếp nhận các issue đã vượt quá giới hạn thử lại.

예비 주제 1은 Jev와 활용이다.
Jev는 TypeSafe AI의 System One 결정 모델로 2026년 9월 15일 얼리 액세스로 출시되었으며, 긴 텍스트 대신 선택·점수·예/아니요 확률 같은 타입화 결정을 신뢰도와 함께 반환한다.
활용 포인트는 세 가지다.
첫째, 코드가 텍스트 파싱 없이 결정값을 받아 직접 분기할 수 있다.
둘째, 큰 모델 앞단의 1차 필터로 두면 분류 작업에서 정확도를 유지하면서 비용을 낮추고 속도를 높일 수 있다.
셋째, 에이전트 루프의 라우팅·분류·스코어링 같은 소규모 판단을 위임해 비용과 속도를 최적화한다.
출처: Jev 실측 비교, Jev 개념 설명, Jev와 LLM 비교 분석. 이 주제는 5–10분 설명용 뼈대이며 전문 원고가 아니다.

Chủ đề dự phòng 1 là Jev và cách khai thác.
Jev là mô hình quyết định System One của TypeSafe AI, ra mắt early access ngày 15 tháng 9 năm 2026, trả về quyết định đã định kiểu như lựa chọn·điểm số·xác suất có/không kèm độ tin cậy thay vì văn bản dài.
Có ba điểm khai thác.
Thứ nhất, mã nguồn nhận giá trị quyết định để rẽ nhánh trực tiếp mà không cần phân tích văn bản.
Thứ hai, đặt làm bộ lọc đầu vào trước mô hình lớn thì giữ được độ chính xác trên tác vụ phân loại mà vẫn giảm chi phí và tăng tốc độ.
Thứ ba, ủy thác các phán đoán nhỏ trong vòng lặp agent như định tuyến·phân loại·chấm điểm để tối ưu chi phí và tốc độ.
Nguồn: so sánh đo thực tế Jev, giải thích khái niệm Jev, phân tích so sánh Jev và LLM. Chủ đề này là dàn ý giải thích 5–10 phút, không phải bản thảo đầy đủ.

예비 주제 2는 서브 에이전트 병목 해결이다.
병목의 원인은 세 가지다.
여러 에이전트가 같은 컨텍스트를 두고 다투는 컨텍스트 경합, 앞 작업이 끝나야 다음이 시작되는 순차 의존, 사람이 리뷰하지 못해 일이 쌓이는 리뷰 적체가 그것이다.
대책도 세 가지다.
일을 잘게 나누는 작업 분할, 나눈 일을 동시에 돌리는 독립 실행, 끝난 결과를 하나로 모으는 결과 취합이다.
이 주제는 5–10분 설명용 뼈대이며 전문 원고가 아니다.

Chủ đề dự phòng 2 là xử lý tắc nghẽn sub-agent.
Nguyên nhân tắc nghẽn có ba thứ.
Xung đột ngữ cảnh khi nhiều agent tranh nhau cùng ngữ cảnh, phụ thuộc tuần tự khi việc sau phải chờ việc trước xong mới bắt đầu, và tồn đọng review khi việc dồn lại vì con người chưa review kịp.
Đối sách cũng có ba thứ.
Chia nhỏ công việc để cắt việc thành miếng nhỏ, thực thi độc lập để chạy đồng thời các việc đã chia, và tổng hợp kết quả để gom các kết quả đã xong thành một.
Chủ đề này là dàn ý giải thích 5–10 phút, không phải bản thảo đầy đủ.

예비 주제 3은 초파리 뇌 AI 모델이다.
구글 리서치와 HHMI 제넬리아가 2026년 9월에 공개한 수컷 초파리 코넥톰(MaleCNS)은 16만 6천여 개의 뉴런과 약 1만 1천7백 종의 세포형을 담은 배선도로, 전자현미경 절편 수백만 장을 AI로 이어 붙인 3D 재구성이다.
핵심은 이 배선도를 시뮬레이션에 올리면 별도 학습 없이 파리다운 행동이 나온다는 점으로, 마인크래프트·둠 같은 데모가 이를 보여준다.
출처: 구글 리서치 발표, IBM 해설, 코넥톰 다운로드. 이 주제는 5–10분 설명용 뼈대이며 전문 원고가 아니다.

Chủ đề dự phòng 3 là mô hình AI não ruồi giấm.
Connectome ruồi giấm đực (MaleCNS) do Google Research và HHMI Janelia công bố tháng 9 năm 2026 là sơ đồ nối dây với hơn 166.000 neuron và khoảng 11.700 loại tế bào, được tái dựng 3D bằng AI từ hàng triệu lát cắt kính hiển vi điện tử.
Điểm cốt lõi là khi đưa sơ đồ này lên mô phỏng thì hành vi giống ruồi xuất hiện mà không cần huấn luyện thêm, như các demo Minecraft·Doom đã cho thấy.
Nguồn: công bố của Google Research, bài giải thích của IBM, tải connectome. Chủ đề này là dàn ý giải thích 5–10 phút, không phải bản thảo đầy đủ.