Jest to podsumowanie testu modeli językowych (GPT4o, Claude 3 Opus, Gemini 1.5) przy różnych zadaniach związanych z projektowaniem układów elektronicznych. Począwszy od edukacji z elektroniki, poprzez wyszukiwanie elementów elektronicznych, szukaniu w notach katalogowych a skończywszy na połączeniu wszystkiego w działający układ elektroniczny. Duncan Haldane sprawdził, jak sobie poradzą przy projektowaniu układów elektronicznych. Okazuje się, że jeszcze nie zastąpią inżyniera elektroniki
Zadawanie pytań dotyczących elektroniki
Pierwszy test polegał na zadawaniu pytań dotyczących elektroniki za pomocą metody "zero shot", czyli wprost do modelu językowego. Nie wpisujemy do zapytania przykładowych dokumentacji, nie budujemy zaawansowanego zapytania do modelu językowego. Po prostu dajemy pytanie i tyle. Pytanie było związane z radiotechniką i brzmiało: Jaki jest opóźnienie na jednostkę długości ścieżki na płytce drukowanej? Najlepiej w odpowiedzi wypadł Claude 3 Opus. Obecnie prawdopodobnie dużo lepiej poradziłby sobie Claude 3.5 Sonet. Najgorzej wypadł Gemini 1.5 od Google, dając dziwne materiały z Internetu.
Test pokazał, że jeśli chcemy trochę poszerzyć swoją wiedzę i zweryfikujemy podane informacje, to wielkie modele językowe, całkiem dobrze poradzą sobie z naszą edukacją z podstaw elektroniki.
Wyszukiwanie elementów elektronicznych do naszego projektu
Duncan wybrał przykład, w którym poszukiwał części do czegoś wyjątkowego: sterownika silnika robota, który jest połączony za pomocą optycznego Ethernetu, zamiast tradycyjnych rozwiązań CAN. Chciał, aby kable były mniejsze, wytrzymałe na skręcanie i wstrząsy oraz aby mogły obsługiwać setki urządzeń. Poprosił AI o pomoc w wyborze części do optycznych złączy, transceiverów oraz urządzenia sieciowego Ethernet.
Niestety, wyniki AI były rozczarowujące. Modele AI miały trudności z zrozumieniem specyfiki zadania i często proponowały niewłaściwe części. Przykładowo, AI sugerowało użycie dużych transceiverów SFP, które są zazwyczaj stosowane w dużych centrach danych, a nie w kompaktowych robotach.
Wyszukiwanie następowało ponownie metodą "zero shot", czyli bez wklejania dokumentacji czy przy braku dostępu do baz elementów elektronicznych. Okazuje się, że modele językowe są wytrenowane na bardzo ograniczonych informacjach o częściach elektronicznych.
Wyszukiwanie w notach katalogowych
Później sprawdzono, jak modele językowe radzą sobie z dokumentacjami, które zawierają ogromne ilości danych o danym elemencie elektronicznym. Autor testował na trzy sposoby:
- Kopiowanie/wklejanie z PDF-a do promptu.
- Przechwytywanie części jako obraz i interpretacja obrazu przez LLM.
- Przesyłanie całego PDF-a.
Do eksperymentu użył Nordic nRF5340 WLCSP. Mały chip Bluetooth o wymiarach 4,0 x 4,4 mm, z kartą katalogową liczącą 820 stron.
Najlepiej poradził sobie model Gemini 1.5, zapewne z powodu możliwości wklejania dużej zawartości tekstu.
Poprawnie poradził sobie z znalezieniem i wypisaniem pinów dla nRF5340 w formie tabelki. Poprawnie odczytał pady i obudowę układu.
Reasumując wielkie modele językowe bardzo dobrze nadają się do znajdywania informacji w tekście, ekstrakcji tekstu oraz modyfikacjami tekstu (w tym kodu). Nic dziwnego, w zasadzie do tego zostały głównie stworzone, a dopiero później dodano obsługę interakcji z człowiekiem w postaci Chatu.
Projektowanie układu
Autor zauważył, że modele językowe (LLM) potrafią zrozumieć obraz schematu na tyle dobrze, aby w większości przypadków przekształcić go w netlistę. Ale czy potrafią zaprojektować cały układ? Zadanie polegało na zaprojektowaniu przedwzmacniacza dla mikrofonu elektretowego, który wzmacniałby i filtrował sygnał audio do próbkowania przez przetwornik ADC. Ponownie wygrał tutaj Claude 3 Opus (Obecnie Claude 3.5 Sonet powinien generować jeszcze lepsze rezultaty).
Modele generują kod poprawny składniowo, ale niepoprawny pod względem funkcjonalnym. Wygenerowane obwody były trzykrotnie droższe i większe niż projekt stworzony przez inżyniera z Texas Instruments. AI miała problemy z generowaniem szczegółowych netlist, ale radziła sobie lepiej przy tworzeniu kodu wyższego poziomu.
Podsumowanie
Projektowanie układów elektronicznych i płytek drukowanych wymaga dużej precyzji, aby wszystkie szczegóły były poprawne - tutaj w tym momencie modele językowe się nie nadają. Może gdyby zastosować jakąś specjalnie wytrenowaną "super wizję" modelu?
Problemem jest brak kontekstu dotyczących schematów czy płytek. Co to robi? Skąd wiadomo, że to jest dobre? Czasami są jakieś komentarze na schemacie lub obliczenia, ale tak naprawdę wszystko znajduje się w głowie inżyniera - projektanta. A przecież modele językowe bazują na języku, czy na rozbudowanych opisach. Tak naprawdę, aby model dobrze działał, inżynier, który projektował układ powinien wszystko krok po kroku opisywać (szczegółowa dokumentacja), co to jest, do czego służy, jaki był jego zamysł przy projektowaniu takiego a nie innego układu, takich połączeń, czy wyboru takich elementów elektronicznych. Tych danych dla modelów językowych nie posiadamy. Stąd ciężko oczekiwać, że modele językowe będą posiadały jakąś wiedzę o bardziej skomplikowanych układach elektronicznych niż zwykły wzmacniacz na tranzystorze (książka), czy popularny mikrokontroler (nota katalogowa, repozytorium Githuba)
Test autora wykazał, że modele językowe mogą być przydatne do pisania kodu. Mogą być bardzo pomocne, aby się nauczyć czegoś nowego - oczywiście później weryfikując dane w innych źródłach.
Modele dobrze sobie radzą z wyciąganiem różnych danych z pomieszanego tekstu. Niestety mają poważne problemy przy podejmowaniu złożonych decyzji przy skomplikowanych projektach. Bez wyspecjalizowanych modeli np. wytrenowanych na dokumentacjach elektronicznych czy wytrenowanych do generowania netlist, raczej nie mamy dużej szansy na poprawę.
Wniosek z tego taki, że jeszcze nie zastąpią inżyniera elektroniki i jeszcze sporo czasu minie zanim stworzą same Terminatora bez udziału człowieka
Źródło testu:
https://blog.jitx.com/jitx-corporate-blog/testing-generative-ai-for-circuit-board-design
Co myślą na ten temat użytkownicy hacker news?
1. Sonnet 3.5 jest uważany za lepszy od innych modeli w zadaniach związanych z projektowaniem obwodów.
2. Wykorzystanie LLM do projektowania obwodów PCB pokazuje ograniczenia modeli zero-shot.
3. W specjalistycznych dziedzinach LLM wymagałby dostrojenia, aby być użytecznym.
4. Użytkownicy są sceptyczni co do możliwości LLM w zrozumieniu złożonych zadań.
5. LLM mogą być użyteczne w generowaniu kodu i wyciąganiu danych z dokumentów.
6. Generatywne AI może być użyteczne w projektowaniu PCB, ale wymaga dalszych badań.
7. Użytkownicy zauważają, że AI może generować schematy, które są niekompletne lub błędne.
8. AI może być użyteczne w tworzeniu bibliotek komponentów.
9. Użytkownicy są sceptyczni co do możliwości AI w rozwiązywaniu problemów specyficznych dla domeny.
Przy tłumaczeniu i podsumowaniu komentarzy wspomagano się modelem językowym GPT-4o. Podsumowanie komentarzy może zawierać błędy.
Obrazek wygenerowano przy użyciu modelu Dall-E3
Posiadacie jakieś swoje doświadczenia z modelami językowymi przy projektowaniu układów elektronicznych? U mnie głównie generowanie kodu dla Arduino czy ESP32
Zadawanie pytań dotyczących elektroniki
Pierwszy test polegał na zadawaniu pytań dotyczących elektroniki za pomocą metody "zero shot", czyli wprost do modelu językowego. Nie wpisujemy do zapytania przykładowych dokumentacji, nie budujemy zaawansowanego zapytania do modelu językowego. Po prostu dajemy pytanie i tyle. Pytanie było związane z radiotechniką i brzmiało: Jaki jest opóźnienie na jednostkę długości ścieżki na płytce drukowanej? Najlepiej w odpowiedzi wypadł Claude 3 Opus. Obecnie prawdopodobnie dużo lepiej poradziłby sobie Claude 3.5 Sonet. Najgorzej wypadł Gemini 1.5 od Google, dając dziwne materiały z Internetu.
Test pokazał, że jeśli chcemy trochę poszerzyć swoją wiedzę i zweryfikujemy podane informacje, to wielkie modele językowe, całkiem dobrze poradzą sobie z naszą edukacją z podstaw elektroniki.
Wyszukiwanie elementów elektronicznych do naszego projektu
Duncan wybrał przykład, w którym poszukiwał części do czegoś wyjątkowego: sterownika silnika robota, który jest połączony za pomocą optycznego Ethernetu, zamiast tradycyjnych rozwiązań CAN. Chciał, aby kable były mniejsze, wytrzymałe na skręcanie i wstrząsy oraz aby mogły obsługiwać setki urządzeń. Poprosił AI o pomoc w wyborze części do optycznych złączy, transceiverów oraz urządzenia sieciowego Ethernet.
Niestety, wyniki AI były rozczarowujące. Modele AI miały trudności z zrozumieniem specyfiki zadania i często proponowały niewłaściwe części. Przykładowo, AI sugerowało użycie dużych transceiverów SFP, które są zazwyczaj stosowane w dużych centrach danych, a nie w kompaktowych robotach.
Wyszukiwanie następowało ponownie metodą "zero shot", czyli bez wklejania dokumentacji czy przy braku dostępu do baz elementów elektronicznych. Okazuje się, że modele językowe są wytrenowane na bardzo ograniczonych informacjach o częściach elektronicznych.
Wyszukiwanie w notach katalogowych
Później sprawdzono, jak modele językowe radzą sobie z dokumentacjami, które zawierają ogromne ilości danych o danym elemencie elektronicznym. Autor testował na trzy sposoby:
- Kopiowanie/wklejanie z PDF-a do promptu.
- Przechwytywanie części jako obraz i interpretacja obrazu przez LLM.
- Przesyłanie całego PDF-a.
Do eksperymentu użył Nordic nRF5340 WLCSP. Mały chip Bluetooth o wymiarach 4,0 x 4,4 mm, z kartą katalogową liczącą 820 stron.
Najlepiej poradził sobie model Gemini 1.5, zapewne z powodu możliwości wklejania dużej zawartości tekstu.
Poprawnie poradził sobie z znalezieniem i wypisaniem pinów dla nRF5340 w formie tabelki. Poprawnie odczytał pady i obudowę układu.
Reasumując wielkie modele językowe bardzo dobrze nadają się do znajdywania informacji w tekście, ekstrakcji tekstu oraz modyfikacjami tekstu (w tym kodu). Nic dziwnego, w zasadzie do tego zostały głównie stworzone, a dopiero później dodano obsługę interakcji z człowiekiem w postaci Chatu.
Projektowanie układu
Autor zauważył, że modele językowe (LLM) potrafią zrozumieć obraz schematu na tyle dobrze, aby w większości przypadków przekształcić go w netlistę. Ale czy potrafią zaprojektować cały układ? Zadanie polegało na zaprojektowaniu przedwzmacniacza dla mikrofonu elektretowego, który wzmacniałby i filtrował sygnał audio do próbkowania przez przetwornik ADC. Ponownie wygrał tutaj Claude 3 Opus (Obecnie Claude 3.5 Sonet powinien generować jeszcze lepsze rezultaty).
Modele generują kod poprawny składniowo, ale niepoprawny pod względem funkcjonalnym. Wygenerowane obwody były trzykrotnie droższe i większe niż projekt stworzony przez inżyniera z Texas Instruments. AI miała problemy z generowaniem szczegółowych netlist, ale radziła sobie lepiej przy tworzeniu kodu wyższego poziomu.
Podsumowanie
Projektowanie układów elektronicznych i płytek drukowanych wymaga dużej precyzji, aby wszystkie szczegóły były poprawne - tutaj w tym momencie modele językowe się nie nadają. Może gdyby zastosować jakąś specjalnie wytrenowaną "super wizję" modelu?
Problemem jest brak kontekstu dotyczących schematów czy płytek. Co to robi? Skąd wiadomo, że to jest dobre? Czasami są jakieś komentarze na schemacie lub obliczenia, ale tak naprawdę wszystko znajduje się w głowie inżyniera - projektanta. A przecież modele językowe bazują na języku, czy na rozbudowanych opisach. Tak naprawdę, aby model dobrze działał, inżynier, który projektował układ powinien wszystko krok po kroku opisywać (szczegółowa dokumentacja), co to jest, do czego służy, jaki był jego zamysł przy projektowaniu takiego a nie innego układu, takich połączeń, czy wyboru takich elementów elektronicznych. Tych danych dla modelów językowych nie posiadamy. Stąd ciężko oczekiwać, że modele językowe będą posiadały jakąś wiedzę o bardziej skomplikowanych układach elektronicznych niż zwykły wzmacniacz na tranzystorze (książka), czy popularny mikrokontroler (nota katalogowa, repozytorium Githuba)
Test autora wykazał, że modele językowe mogą być przydatne do pisania kodu. Mogą być bardzo pomocne, aby się nauczyć czegoś nowego - oczywiście później weryfikując dane w innych źródłach.
Modele dobrze sobie radzą z wyciąganiem różnych danych z pomieszanego tekstu. Niestety mają poważne problemy przy podejmowaniu złożonych decyzji przy skomplikowanych projektach. Bez wyspecjalizowanych modeli np. wytrenowanych na dokumentacjach elektronicznych czy wytrenowanych do generowania netlist, raczej nie mamy dużej szansy na poprawę.
Wniosek z tego taki, że jeszcze nie zastąpią inżyniera elektroniki i jeszcze sporo czasu minie zanim stworzą same Terminatora bez udziału człowieka
Źródło testu:
https://blog.jitx.com/jitx-corporate-blog/testing-generative-ai-for-circuit-board-design
Co myślą na ten temat użytkownicy hacker news?
1. Sonnet 3.5 jest uważany za lepszy od innych modeli w zadaniach związanych z projektowaniem obwodów.
2. Wykorzystanie LLM do projektowania obwodów PCB pokazuje ograniczenia modeli zero-shot.
3. W specjalistycznych dziedzinach LLM wymagałby dostrojenia, aby być użytecznym.
4. Użytkownicy są sceptyczni co do możliwości LLM w zrozumieniu złożonych zadań.
5. LLM mogą być użyteczne w generowaniu kodu i wyciąganiu danych z dokumentów.
6. Generatywne AI może być użyteczne w projektowaniu PCB, ale wymaga dalszych badań.
7. Użytkownicy zauważają, że AI może generować schematy, które są niekompletne lub błędne.
8. AI może być użyteczne w tworzeniu bibliotek komponentów.
9. Użytkownicy są sceptyczni co do możliwości AI w rozwiązywaniu problemów specyficznych dla domeny.
Przy tłumaczeniu i podsumowaniu komentarzy wspomagano się modelem językowym GPT-4o. Podsumowanie komentarzy może zawierać błędy.
Obrazek wygenerowano przy użyciu modelu Dall-E3
Posiadacie jakieś swoje doświadczenia z modelami językowymi przy projektowaniu układów elektronicznych? U mnie głównie generowanie kodu dla Arduino czy ESP32
Fajne? Ranking DIY
