Ja — och just ditt exempel med
alla Sveriges kyrkor är faktiskt ett ganska bra exempel på ett problem där AI och klassisk optimering börjar mötas.
En viktig detalj först: Svenska kyrkan uppger för 2026 att det finns
3 320 invigda kyrkor i Sverige, inte riktigt 4 000. Det är alltså ett TSP med ungefär 3 300 noder om man begränsar sig till Svenska kyrkans invigda kyrkor. (
Svenska Kyrkan)
Hur bra är AI på TSP?
Det finns egentligen två ganska olika saker som kallas "AI" här.
1. AI som försöker lösa TSP direkt
Det finns forskning där neurala nätverk och reinforcement learning tränas för att själva konstruera en bra rundtur. Ett exempel är H-TSP, som har testats på problem med upp till
10 000 noder. Författarna rapporterar att deras metod på stora testproblem kunde ge lösningar med ungefär
3,4 % gap mot referenslösningen, samtidigt som beräkningstiden kunde vara mycket kortare än för vissa sökbaserade metoder. (
arXiv)
Det är imponerande, men det finns en viktig hake:
AI är normalt bra på att hitta en mycket bra lösning snabbt, men inte på att bevisa att lösningen är den absolut bästa.
Det är en ganska fundamental skillnad mot klassisk optimering.
Det finns också nyare forskning där man kombinerar AI med klassiska optimeringsalgoritmer. Ett intressant exempel från 2025/2026 använder en vision-language-modell för att identifiera lovande delar av ett stort TSP och sedan låter en vanlig optimeringssolver göra själva finliret. På testproblem med
1 000–88 000 noder rapporteras mycket små optimalitetsgap. (
arXiv)
Det är faktiskt den typ av hybridlösning jag tror är mest intressant för ditt kyrkoproblem.
2. Klassiska TSP-program är fortfarande väldigt bra
Här kommer den lite överraskande delen:
För att faktiskt lösa ditt problem skulle jag inte börja med en AI.
Jag skulle använda en specialiserad optimeringssolver.
Ett exempel är Googles
OR-Tools, som är gratis och open source och har stöd för TSP och många betydligt mer komplicerade varianter av Vehicle Routing Problem. Det finns Python-bindningar, så det skulle vara ganska lätt att använda från ett Python-projekt. (
Google for Developers)
Ännu mer specialiserat är
Concorde, som är utvecklat specifikt för TSP och är extremt starkt på stora rena TSP-problem. Google nämner uttryckligen Concorde som en solver som kan överträffa OR-Tools för mycket stora TSP. (
Google for Developers)
Problemet är förstås att TSP är NP-svårt. Antalet möjliga rundturer växer enormt:
- 10 städer → 181 440 olika rundturer
- 20 → ~6 × 10¹⁶
- 100 → ~10¹⁵⁸
- 3 300 → ett fullständigt astronomiskt antal.
Så en solver kan inte prova alla möjligheter.
I stället använder den saker som
branch-and-bound, cutting planes, local search, heuristics och metaheuristics för att eliminera enorma mängder av möjligheter. OR-Tools beskriver exempelvis guided local search och andra metoder för att förbättra en redan bra rutt. (
Google for Developers)
Men ditt kyrkoproblem är faktiskt mer intressant än ett vanligt TSP
Här tycker jag att din idé blir riktigt kul.
Om frågan är:
"Jag vill cykla från min bostad, besöka varje kyrka i Sverige exakt en gång och sedan komma hem."
då är det inte riktigt bara ett vanligt TSP.
Vi behöver exempelvis bestämma:
Vad är en "kostnad" mellan två kyrkor?
Det kan vara:
- fågelvägsavstånd
- bilvägsavstånd
- cykelvägsavstånd
- faktiskt cykelbart avstånd
- höjdskillnad
- eller en kombination.
Och för dig skulle jag definitivt välja
cykelvägnätet, inte fågelvägen.
Dessutom kan vi lägga till saker som:
- start = din bostad
- slut = din bostad
- undvik motorvägar
- undvik grusvägar om du vill
- maximera andelen asfalt
- kanske undvika färjor
- kanske minimera höjdmetrar
- kanske ha en maximal etapp på exempelvis 150 km
- kanske dela upp hela rundan i 50–100 dagsetapper.
Då har vi gått från det klassiska TSP till ett betydligt mer realistiskt
Vehicle Routing / Tour Planning-problem.
OR-Tools är uttryckligen byggt för sådana utvidgningar, inklusive exempelvis tidsfönster, kapacitetsbegränsningar och andra constraints. (
Google for Developers)
Och här tror jag AI skulle vara riktigt användbart
Jag skulle kunna tänka mig en pipeline ungefär så här:
1. Datainsamling
Hämta koordinater för de ~3 320 kyrkorna.
2. Vägnät
Bygg ett cykelbart vägnät över Sverige.
3. Avståndsmatris
Beräkna cykelavstånd mellan kyrkorna.
Det blir ungefär
3 320 × 3 320 ≈ 11 miljoner
avstånd.
4. Klassisk optimering
Låt exempelvis OR-Tools, Concorde eller LKH-3 försöka hitta en extremt bra rundtur.
5. AI ovanpå detta
Här kan en AI hjälpa till att exempelvis:
- identifiera problemområden i rutten
- föreslå alternativa segment
- prioritera vilka delar som bör optimeras om
- hantera mer "mänskliga" önskemål
- dela upp den gigantiska rundan i vettiga cykeletapper.
Det är ungefär samma filosofi som den nyare forskningen jag nämnde ovan:
AI behöver inte ersätta optimeringsalgoritmen; den kan hjälpa optimeringsalgoritmen. (
arXiv)
En sak till: vi skulle faktiskt kunna prova detta
Det här är ett sådant problem där jag tror att det vore ganska roligt att göra ett riktigt experiment tillsammans.
Vi skulle kunna börja
mycket mindre än 3 320 kyrkor.
Till exempel:
Alla kyrkor i Västmanland.
Sedan skulle vi kunna bygga en Python-version som:
- hämtar kyrkornas koordinater,
- beräknar cykelavstånden,
- löser TSP:t,
- ritar ut rutten på en karta,
- räknar ut total distans och höjdmetrar.
Sedan kan vi gradvis skala upp:
Västmanland → Svealand → hela Sverige.
Och då kan vi dessutom göra ett riktigt intressant experiment: jämföra
en klassisk TSP-solver mot en AI-baserad metod och se hur mycket sämre/bättre AI-lösningen faktiskt blir.
För just den typen av experiment skulle jag säga att
specialiserad optimeringsprogramvara är betydligt mer intressant än att bara fråga en LLM "hitta den kortaste rutten". LLM:n är bra på att hjälpa oss bygga systemet; den är inte den komponent jag skulle anförtro själva 3 300-nodersoptimeringen åt.
api.svenskakyrkan.se
