MarkItDown päätyy usein web-scrapereiden joukkoon, mutta se on väärä lokero. Sillä ei ole crawleria, JavaScript-moottoria eikä kykyä hakea URL-osoitetta ja siivota sivun ylimääräistä krääsää pois. Sen tehtävä on ottaa jo hallussasi olevat tiedostot — PDF, Word-dokumentti, taulukko, diaesitys — ja muuntaa ne Markdowniksi, jota kielimalli voi lukea.
Käytin pari viikkoa Microsoftin MarkItDownia oikeiden dokumenttien läpikäyntiin yhdellä Macilla, pisteyttäen jokaisen taulukon ennen ajoa kirjoittamani manifestin perusteella ja mitaten jokaisen muunnoksen keston. Lyhyt yhteenveto: siistillä syötteellä se on nopea ja luotettava, mutta paketointi piilottaa 73 Mt:n koneoppimisajoympäristön, jota et ehkä tarvitse, ja taulukot hajoavat tavoilla, jotka läpäisevät testin "selvisikö teksti?" mutta kaatuvat testissä "onko tieto oikeassa sarakkeessa?". Tässä koko kuva numeroineen.
Mikä MarkItDown oikeasti on
MarkItDown on Microsoftin Python-työkalu, joka muuntaa tiedostoja ja Office-dokumentteja Markdowniksi LLM-käyttöön optimoidussa muodossa. Syötä sille PDF, .docx, .xlsx, .pptx, kuva, HTML-tiedosto tai muu vastaava formaatti, ja se palauttaa Markdownia. Sitä voi käyttää kolmella tavalla: komentoriviltä (markitdown file.pdf -o out.md tai stdinistä putkittamalla), Python-API:n kautta (MarkItDown().convert(...)) sekä haluttaessa MCP-palvelimena agenttityönkulkuja varten.
Tärkein rajaus on se, mitä se ei tee — ja tämä käy ilmi sekä README:stä että testauksesta: ei crawlingia, ei JS-renderöintiä, ei linkkien seuraamista, ei sivutusta eikä readability-tyyppistä pääsisällön poimintaa. Se muuntaa koko dokumentin. Sinä tuot byteina syötteen, se standardoi sen. Juuri tämä ero ratkaisee, kuuluuko työkalu sinun työkalupakkiisi vai ei, joten palaan siihen vielä monta kertaa.
Itse repo näyttää GitHubin pintamittareilla massiiviselta — 165 282 tähteä ja 11 790 forkkausta heinäkuun 2026 puolivälissä, MIT-lisensoitu, uusin julkaisu (v0.1.6) julkaistu 2026-05-26. Tähtimäärä kertoo ennen kaikkea Microsoft-organisaation repositorion yleisestä LLM-työkaluinnostuksesta, ei niinkään muunnosytimen kypsyydestä. Avoimia issueita on myös 833, ja osa niistä kannattaa tuntea ennen asennusta (lisää siitä alempana).
HTML Markdowniksi: nopea ja täydellinen, myös sivun ylimääräinen sisältö mukana
Koska muun scrapereihin liittyvän arviointisarjani neljä web-fixtureä ovat samat, syötin MarkItDownille identtiset paikalliset HTML-tiedostot — en arvioidakseni sitä scraperina, vaan nähdäkseni, kuinka hyvä sen HTML→Markdown-muunnos on. Hyvin jäsennellyillä sivuilla se on oikeasti hyvä.
Kaikki neljä sivua muuntuivat perusasennuksella ilman lisäosia, ja jokainen rungon sisältöä mittaava testi säilyi. Wikipedian "Web scraping" -artikkeli (226 KB) säilytti otsikkopuunsa oikein — yksi h1, seitsemän h2:ta, kaksitoista h3:ta, jotka vastaavat artikkelin todellista rakennehierarkiaa — ja 418 linkkiä säilyi muodossa [teksti](url). Scrape This Site -sivun forms-sivun 26×9 jääkiekko-tilastotaulukko muuttui siistiksi 27-riviseksi GFM-putkitaulukoksi (otsikko + erotin + 26 datariviä), tyhjine soluineen päivineen. Nopeus ei ollut ongelma: mediaani 48 ms pienellä quotes-sivulla ja 352 ms 226 KB:n Wikipedia-sivulla.
Tässä on kuitenkin koukku, ja se on suunnitteluratkaisu eikä bugi. MarkItDown ei poista sivun ylimääräistä sisältöä. Se muuntaa koko <body>-osion, joten sivun kehykset ja valikot kulkevat mukana — ja tämä ylimääräinen osuus kasvaa sen mukaan, kuinka paljon kehystä sivulla on.
| Sivu | Tuotoksen merkkimäärä | Otsikot (h1/h2/h3) | Linkit | Sivukehyksen rivit |
|---|---|---|---|---|
| Books to Scrape | 10,478 | 1 / 0 / 0 | 94 | 0.6% (1/159) |
| Quotes to Scrape | 2,973 | 1 / 1 / 0 | 55 | 1.2% (1/86) |
| ScrapeThisSite forms | 3,385 | 1 / 0 / 0 | 31 | 6.7% (5/75) |
| Wikipedia Web scraping | 60,159 | 1 / 7 / 12 | 418 | 12.4% (42/338) |
Lähes kehyksettömällä Books-etusivulla vain 0,6 % tuotoksen riveistä on sivukehystä. Wikipediassa osuus on 12,4 % — 42 rivistä 338 ei-tyhjää riviä on tyyppiä "siirry sisältöön", "näytä/piilota sisällysluettelo", "22 kieltä", "haettu sivulta", eväste- ja lisenssijalusteet. Myös Wikipedian ylläpitobannerit ("This article needs additional citations") renderöityvät uskollisesti kaksisarakkeisiksi putkitaulukoiksi, mistä syntyy yhdeksän taulukkoriviä sivulla, jolla ei ole varsinaista datataulukkoa.
Tämä ei ole MarkItDownin virhe. Se on koko dokumentin muuntaja, ei readability-tyyppinen sisällönpoimija: uskollinen HTML→Markdown on eri työ kuin siisti artikkelipoiminta. Trafilaturan ja Firecrawl-tyyppisten työkalujen tavoite on palauttaa vain pääsisältö; MarkItDown palauttaa koko sivun. Sen sisällä _html_converter.py poistaa <script>- ja <style>-elementit, ja syöttää sitten koko body-osan markdownify-kirjastolle — mitään pääsisällön heuristiikkaa ei ole mukana. Jos haluat vain artikkelin, tämä on väärä kerros.
Kotikenttä: PDF, DOCX, XLSX, PPTX
Dokumentit ovat MarkItDownin ydinalue. Testasin sitä oikeilla julkisilla tiedostoilla — arXiv-paperilla, jossa on tekstikerros, Bitcoinin whitepaperilla, pelkästä kuvasta koostuvalla skannatulla PDF:llä, jonka renderöin niin, että siinä ei ollut lainkaan tekstiä, sekä MarkItDownin omasta testisuitesta otetuilla DOCX/XLSX/PPTX-tiedostoilla (UUID-tunnisteilla varustettuina, jotta havaitsen hiljaisen sisällön katoamisen).
| Dokumentti | Syöte | Tuotoksen merkkimäärä | Testit | Mediaaniaika | Huomiot |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF tekstikerroksella) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | title, "Transformer", "BLEU", "References" kaikki mukana |
| Bitcoin whitepaper (9 s PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" mukana |
| Skannattu PDF (ei tekstikerrosta) | 89 KB | 0 | 0/4 | 15 ms | tyhjä tulos, ei virhettä, ei OCR:ää |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | otsikot + GFM-taulukko; upotetut UUID:t säilyvät |
| DOCX yhtälöillä | 15 KB | 240 | — | 101 ms | Office Math säilyy LaTeX-muodossa |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | jokainen taulukko → ## SheetName + GFM-taulukko |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | diaanumeromerkinnät, taulukot, kaavio → taulukko |
Tekstin palautus oli tekstikerroksellisissa PDF:issä erinomainen — 7/7 ennalta määritellyistä testeistä arXiv-artikkelissa "Attention Is All You Need" ja 6/6 Bitcoin whitepaperissa — eikä yksikään Office-tiedosto menettänyt ainuttakaan UUID-sentineliä, joten ylläpitäjien omissa regressio-fixtureissä ei ollut hiljaista sisällönhukkaa. Yksi kapea mutta tärkeä voitto: DOCX-polku (mammothin kautta) säilyttää Office Math -yhtälöt LaTeXina ja muuntaa equations.docx-tiedoston oikeaksi $$...$$-matematiikaksi. Jos syötät LLM:lle matematiikkapainotteisia Word-dokumentteja, tämä on aito, vaikkakin kapea, vahvuus, josta en löytänyt juuri muuta mainintaa.
Tästä kentästä nousee kaksi huomiota, jotka ansaitsevat oman huomionsa, koska ne ovat juuri niitä, jotka todennäköisimmin purevat sinua.
Skannattu PDF, joka katoaa tyhjyyteen
Kun syötät MarkItDownille pelkästä kuvasta koostuvan PDF:n ilman tekstikerrosta, tuloksena on tyhjä merkkijono. Nolla merkkiä, ei poikkeusta, ei varoitusta — muunnos valmistuu noin 15 ms:ssa, koska mitään ei ole poimittavaa. MarkItDownin PDF-polku tekee vain tekstin purkua (pdfminer ja pdfplumber taustalla), eikä perusasennuksessa eikä yhdessäkään pip-lisäosassa ole OCR:ää.
Tämä on merkittävää eräajossa. Kehittäjä, joka syöttää kansion täynnä PDF:iä, joissa osa on skannauksia, saa noista tiedostoista hiljaisesti tyhjiä tuloksia ilman minkäänlaista merkkiä siitä, että jotain jäi väliin. Varmistin, ettei fixture ollut rikki, ajamalla pdfminerin extract_text-funktion suoraan tiedostoon — tulos oli nolla poimittua merkkiä, ei tekstikerrosta, vahvistettu — joten tyhjä tuotanto on MarkItDownin todellinen käyttäytyminen aidossa skannissa. Tämä toistaa pitkään avoinna olleen OCR-varamenetelmän puutteen (#1268), jota on seurattu upstreamissa jo jonkin aikaa. Dokumentoitu vaihtoehto on Azure Document Intelligence -taustaratkaisu tai plugin; kumpikaan ei kuulu oletusasennukseen.
PDF:t tulevat ulos litteänä tekstinä, eivät rakenteena
Molemmissa tekstikerroksellisissa PDF:issä MarkItDown tuotti nolla Markdown-otsikkomerkintää. PDF ei sisällä semanttisia otsikkotageja, eikä MarkItDown päättelee niitä fonttikoon perusteella, joten jokainen rivi päätyy varsinaiselle tekstitasolle. Tekstin palautus on korkea; rakenne on litteä.
Tämä ei ole vain minun havaintoni. Julkiset kolmannen osapuolen benchmarkit pisteyttävät MarkItDownin PDF-otsikkohierarkian noin 0,0:aan ja taulukkojen fidelityn noin 0,27:ään, mikä on selvästi alle Doclingin TableFormer-pohjaisen 0,88:n (katso MarkItDown vs Docling vs Marker -vertailu ja READoc-benchmark). Omat fixture-tulokseni vastaavat niitä, mikä vahvistaa näyttöä: lukuni ovat linjassa ulkoisen lähteen kanssa. Sama benchmark-aineisto kertoo myös trade-offin: MarkItDown on noin 100× nopeampi kuin Docling, mikä sopii yhteen omien sekunteja eikä minuutteja vievien ajojeni kanssa verrattuna layout-mallityökaluihin. Johtopäätös: MarkItDown antaa sinulle puhdasta ja nopeaa PDF:n tekstiä; se ei anna PDF:n rakennetta. Jos otsikoiden ja taulukoiden on säilyttävä, oikea työkalu on layout-malliin perustuva vaihtoehto kuten Docling tai Marker.
Taulukot: sisältö säilyy aina, rakenne ei aina
Taulukot ovat se kohta, jossa "selvisikö teksti?" ja "onko tieto käyttökelpoinen?" erkanevat toisistaan, joten rakensin 13 tapauksen matriisin — yksi <table> per tapaus, jokainen pisteytetty ennen ajoa kirjoitetun manifestin perusteella — kartoittaakseni tarkasti, mitkä muodot kestävät ja mitkä rikkoutuvat.
Pääviesti: MarkItDown ei koskaan kadottanut taulukon sisältöä. Kaikissa 13 tapauksessa 100 % ennalta määritellyistä tokeneista säilyi. Rakenteellinen fidelity jakautui kuitenkin kolmeen ryhmään. Seitsemän kolmestatoista tapauksesta tuotti hyvin muodostuneen GFM-ruudukon (plain, header-colspan, 24-column-wide, headerless, empty-cells, block-in-cell ja oikealta vasemmalle luettava arabia). Neljä meni rosoiseksi, koska Markdownilla ei ole käsitettä solun yhdistämiselle, joten rowspan, colspan ja virheelliset lähteet tuottavat lyhyitä rivejä. Ja kaksi meni täysin rikki.
Kaksi rikkoutumista kannattaa nimetä. Sisäkkäinen taulukko (<table> <td>-solun sisällä) litistyy rivin sisään ja pudottaa omat putkimerkkinsä ja erotinrivinsä vanhempaan soluun, jolloin syntyy 14 "sarakkeen" roskarivi. Ja solun sisällä oleva kirjaimellinen |-merkki ei ole escapattu — solun teksti a | b muuttuu kahdeksi sarakkeeksi, x || y kolmeksi — joten kaksisarakkeinen taulukko alkaa tuottaa rivejä, joissa on kaksi, kolme ja neljä saraketta, ja mikä tahansa Markdown-parseri tulkitsee rajat väärin. Outoa kyllä, solun sisällä olevat asteriskit ja backtickit ovat escapattu; putket eivät. Juurisyy on se, että MarkItDownin HTML-polku käyttää markdownifyn oletuslogiikkaa taulukoille, ja sen oma aliluokka korvaa linkit, kuvat ja otsikot mutta ei taulukon soluja. Samanlainen putkien escapausbugi on avoimena ongelmana CSV-muuntimessa (#2019), mutta se korjaus ei koske testaamaani HTML-polkuun.
Hienovaraisin havainto — ja se, jonka haluaisin eniten data-insinöörin näkevän — on rowspan. Tapaus t03 ei vain mene rosoiseksi; se siirtää tietoja hiljaisesti väärään kohdistukseen. rowspan=2-merkintä ("Fruit") kirjoitetaan kerran, ja sen alla oleva rivi muuttuu lyhyeksi kaksisarakkeiseksi riviksi (| Banana | 8 |), jolloin "Banana" päätyy Group-sarakkeen alle Item-sarakkeen sijaan. Kaikki tokenit ovat olemassa. Mutta jos kuluttaja lukee naiivisti "toisen sarakkeen", hän saa väärän arvon. Juuri tällainen bugi läpäisee tekstin säilymisen tarkistuksen ja korruptoi datan hiljaisesti.
Itse span-rajoitus on tunnettu ja seurattu suunnittelurajoite (#1211, #1248) — litteä GFM-putkiruutu ei oikeasti kykene esittämään spanneja tai sisäkkäisyyttä, joten muuntaja vaihtaa rakenteen sisällön täydellisyyteen. Mukana on myös hyviä käytöksiä: headerless-taulukot saavat generoituun tyhjän otsikkorivin (jolloin data ei hiljaisesti nouse otsikoksi), tyhjät solut säilyvät, ja <caption> säilyy tekstirivinä taulukon yläpuolella.
Asennus ja käynnistys: vero, josta "kevyt apuohjelma" ei varoita
Mikään ei yllättänyt minua tässä enempää, ja juuri tässä "kevyt Python-työkalu" -kehys lupaa hieman liikaa.
Ensinnäkin, älä aja pip install 'markitdown[all]'. Python 3.14:ssa se perääntyy hiljaisesti versioon markitdown 0.0.2 — kahden vuoden takaiseen julkaisuun — ja toistin tämän itse puhtaassa virtualenvissä. Syy selviää, kun pinnaaminen tehdään näkyväksi: pip install 'markitdown[all]==0.1.6' antaa virheen, koska [all]-extra lukitsee youtube-transcript-api~=1.0.0-version, ja nykyisessä PyPI:ssä jokainen kyseisen haaran julkaisu vaatii Pythonin <3.14, kun taas ainoat 3.14-yhteensopivat buildit jäävät tämän pinauksen ulkopuolelle. Resolveri siis kävelee lopulta takaisin viimeiseen julkaisuun, jonka riippuvuudet se pystyy täyttämään. Tämä vastaa avoinna olevaa upstream-issuea (#2179). Korjaus on yksinkertainen — pinnaa versio ja asenna lisäosat erikseen: pip install 'markitdown==0.1.6', sitten pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Kaikki nämä ratkeavat siististi; vain yhdistetty [all]-paketti sisältää ongelmallisen pinauksen. (Tämä ansa riippuu Python-versiosta — Python 3.13:ssa tai sitä vanhemmissa gate ei välttämättä pure, joten [all] voi ratketa eri tavalla.)
Toiseksi, jalanjälki. Ydinasennus on 161 Mt (13 Mt:n tyhjä venv + 148 Mt). Tästä onnxruntime (73 Mt) ja numpy (34 Mt) muodostavat yhdessä 107 Mt — 66 % koko ytimen jalanjäljestä — ja molemmat tulevat yhden kovaan riippuvuuden mukana: magika, Googlen ML-pohjainen tiedostotyyppitunnistin. Toisin sanoen tekstimuunnin kuljettaa perusasennuksessaan 73 Mt:n ONNX-inferenssiajoympäristön jo ennen kuin lisäät yhtäkään dokumenttilisäosaa. Kun dokumenttilisäosat lisätään, venv kasvaa 310 Mt:iin. Tämä on paljon kevyempi kuin headless-selaimeen perustuva stack, mutta jos odotit pip install- ja valmis-mikrotyökalua, tiedä että mukana tulee ONNX-ajoympäristö.
Kolmanneksi — ja tämä on koko pakin selvästi uusin havainto, joka läpäisi kaikki kokeilemani uutuustestit — jopa puhtaan asennuksen jälkeen import markitdown maksaa tällä koneella noin 3,35 sekuntia. Kustannus syntyy lähes kokonaan import-vaiheessa: markitdown._markitdown lataa innokkaasti koko muunnosrekisterin (2,56 s kumulatiivinen aika, 76 % kokonaisajasta), mikä vetää mukaan pandasin (594 ms, XLSX-muuntimen kautta), python-pptx:n (427 ms), magikan (354 ms) ja requestsin (270 ms) — vaikka et muuntaisi yhtäkään näistä formaateista. Pitkäkestoisessa palvelussa tämä kustannus tasoittuu merkityksettömäksi. CLI-ajossa tai serverless-cold startissa se on kuitenkin oikea per-prosessi vero, jota "kevyt apuohjelma" ei anna odottaa. (Reilu huomio: tämä on yksi profiloitu ajo, yksi havainto, ei monen ajon jakauma.)
Skaala: se ei kaadu, mutta varaa CPU:a PDF:ille ja RAMia taulukoille
Puskin läpi neljä suurta kohdetta, kukin omassa prosessissaan, jotta edellisen ajon muistijälki ei sotke huippumuistia. Mikään ei kaatunut. Kustannusprofiili on silti vino.
| Kohde | Syöte | Tuotoksen merkkimäärä | Mediaaniaika | Peak RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (492-sivuinen PDF) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50,000 riviä × 8 saraketta | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15-sivuinen PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 riviä × 64 saraketta | 46 KB | 120,129 | 2.9 s | +22 MB |
492-sivuinen NIST-PDF vei mediaanina 192,5 sekuntia — noin 3,2 minuuttia eli 0,39 s/sivu — koska pdfplumber tekee jokaisella sivulla sanapaikkaperusteista lomaketunnistusta. Peak RSS pysyi +40 Mt:ssa, joten kuorma on CPU:ssa, ei muistissa. Jopa 15-sivuinen arXiv-PDF vei 12,6 sekuntia eristetyssä prosessissa, eli noin 3,4× enemmän kuin sama tiedosto lämpimässä tilassa dokumenttisuite-ajossa (3,7 s). Ero on cold-process-kustannus, ja se vahvistaa, että sivukohtainen työ on ajon varsinainen selittäjä, ei pelkkä byte-määrä. Jos haluat yhden siirrettävän luvun tuolle PDF:lle, käytä eristettyä 12,6 s aikaa.
Taulukkolaskentapolku kääntää pullonkaulan toisin päin. 2,1 Mt:n, 50 000 rivin XLSX paisui +374 Mt:n peak RSS:ään (ja 3,7 miljoonaan tuotoksen merkkiin), koska muuntaja lataa koko taulukon ja rakentaa yhden suuren Markdown-merkkijonon. Käytännön ohje on siis suora: suurille PDF:ille varaa minuutteja CPU-aikaa; suurille taulukoille varaa satoja megatavuja RAMia. Nämä ovat yhden koneen lukuja macOS arm64:lla ja Python 3.14:llä, ja sivu- ja rivikohtaiset vakioarvot ovat alustasidonnaisia — mutta muoto (PDF on hidas ja CPU-sidonnainen, XLSX on muistisyöppö, mikään ei kaadu) on se osa, joka siirtyy käytäntöön.
Mihin Thunderbit sopii — ja mihin ei
Kokeile Thunderbitia web-datan poimintaan
Tämä on se vertailu, jossa olisi helppo liioitella, joten vedän rajan huolellisesti. MarkItDown ja Thunderbit ratkaisevat vierekkäisiä, eivät samoja, ongelmia.
MarkItDown muuntaa tiedostoja, jotka sinulla on jo. Thunderbit hakee sivun ensin. Thunderbitin /distill-päätepiste muuntaa live-verkkosivun siistiksi, LLM-valmiiksi Markdowniksi — hoitaen JS-renderöinnin, bottisuojausten ja dynaamisen sisällön käsittelyn, johon MarkItDownilla ei ole välineitä — ja /extract-päätepiste palauttaa skeemaan sopivaa rakenteista JSONia, ei pelkkää raakaa Markdownia. Kehittäjälle tämä on tarjolla API:nä (POST /distill / POST /extract), MCP-palvelimena ja CLI:nä (npx @thunderbit/thunderbit-cli) yhden tekoälymoottorin päällä, saman kuin 100 000+ käyttäjän laajennuksessa.
Eli niillä on päällekkäisyyttä täsmälleen yhdessä asiassa — molemmat voivat tuottaa "LLM-valmista Markdownia" — mutta syötedomaini on eri: Thunderbitin distill ottaa URL:n avoimesta verkosta, MarkItDown ottaa paikallisen tiedoston. Ne eivät ole toistensa suoria korvikkeita, enkä väitä niin. Käytännöllinen pino käyttää molempia: hae ja crawlkaa verkko Thunderbitilla (tai Firecrawl-tyylisellä palvelulla), ja normalisoi sen lisäksi myös paikalliset dokumentit — PDF:t, diat ja taulukot — MarkItDownilla. Toinen hoitaa verkon, toinen tiedostokaapin.
Plussat ja miinukset
Vahvuudet
- Koko rungon sisällön palautus siististä HTML:stä (4/4 sivua), otsikkopuut ja linkit säilyvät uskollisesti
- Hyvä PDF/DOCX-tekstin palautus (arXiv 7/7 testit, Bitcoin 6/6) eikä hiljaista sisällönhukkaa ylläpitäjien omissa Office-fixtureissä
- Office Math -yhtälöt säilyvät LaTeXina — aito erikoistapauksen vahvuus
- Ei kaatunut yhdessäkään testatusta skaalakohteesta, aina 492-sivuisesta PDF:stä 50k-riviseen XLSX:ään
- Helppo käyttää: CLI,
convert(), stdin-putkitus ja valinnainen MCP-palvelin - MIT-lisensoitu, aktiivisesti Microsoftin ylläpitämä, issue-seuranta reagoi
Heikkoudet
- Säilyttää sivun ylimääräisen sisällön — Wikipediassa jopa 12,4 % sivukehysrivejä; ei artikkelipoimija
- Taulukot rikkoutuvat spanneihin, sisäkkäisyyksiin ja solun sisäisiin putkiin (2/13 rikki, 4/13 rosoisia), ja rowspan voi siirtää tiedon hiljaisesti väärään sarakkeeseen
- Skannatut/kuvamuotoiset PDF:t palauttavat tyhjän tuloksen ilman OCR:ää ja ilman virheilmoitusta
- PDF-tuotos ei sisällä lainkaan otsikkorakennetta (vastaa julkisia benchmarkeja)
- 161 Mt:n ydinasennus sisältää 73 Mt:n ONNX-ajoympäristön; noin 3,35 s cold import
[all]-extra perääntyy hiljaisesti kahden vuoden takaiseen 0.0.2-versioon Python 3.14:ssa
Kenen kannattaa käyttää sitä — ja kenen ei
Ota MarkItDown käyttöön, jos olet standardoimassa sekalaisen paikallisten dokumenttien kasan — Word, Excel, PowerPoint, tekstikerrokselliset PDF:t — Markdowniksi LLM-putkea varten, ja sinulle on tärkeämpää täydellinen teksti kuin rakenteen säilyminen. Viimeisen vaiheen muuntimena eräajossa, kun syötät mallille puhdasta tekstiä, se on nopea, luotettava ja ilmainen.
Ohita se tai yhdistä siihen jokin toinen työkalu, jos tehtäväsi on jokin näistä: tarvitset verkkosivulta vain pääartikkelin (käytä readability- tai Firecrawl-tyyppistä työkalua); tarvitset PDF:n otsikoiden ja taulukoiden säilyvän ehjinä (tämä on Doclingin tai Markerin aluetta); tai syötteesi sisältävät skannattuja dokumentteja, jotka vaativat OCR:n (tarvitset Azure-taustaratkaisun tai kokonaan toisen työkalun). Ja jos luulit ostavasi scraperin — työkalun, joka hakee ja crawlaa sivuja — tämä ei ole sitä lainkaan.
Tekemäni alustava pisteytys scraper-tyylisellä rubriikilla antaa MarkItDownille 60/100, ja tuo matala kokonaispiste on seurausta siitä, että muunninta arvioidaan crawlerin testillä. Omalla alueellaan sen tekstinuskollisuus on korkea; heikot kohdat ovat rakenteessa (taulukot, PDF-otsikot) ja paketoinnissa (jalanjälki, import, [all]-ansa), eivät tekstin laadussa. Kun arvioit sitä sellaisena kuin se on — tiedostot Markdowniksi muuntavana työkaluna — kyseessä on vankka, hyvin ylläpidetty työkalu, jossa on muutamia teräviä reunoja, jotka kannattaa tuntea ennen tuotantoon kytkemistä.
Usein kysytyt kysymykset
Onko MarkItDown web-scraper?
Ei. Sillä ei ole crawleria, JavaScript-renderöintiä, linkkien seuraamista eikä sivutusta. Se muuntaa tiedostoja ja dokumentteja, jotka sinulla on jo — PDF, DOCX, XLSX, PPTX, kuvat, HTML — Markdowniksi. Jos sinun täytyy hakea ja crawlata live-verkkosivuja, tarvitset Thunderbitin tai Firecrawl-tyyppisen scraping-työkalun; MarkItDown on vaihe, joka tulee sen jälkeen ja muuntaa haetut tai paikalliset tiedostot siistiksi Markdowniksi.
Miksi pip install markitdown[all] asentaa vanhan version?
Python 3.14:ssa [all]-extra lukitsee youtube-transcript-api~=1.0.0-version, ja jokainen kyseisen haaran julkaisu vaatii Pythonin alle 3.14:n. Resolveri ei pysty täyttämään pinnausta, joten se perääntyy hiljaisesti versioon markitdown 0.0.2, joka on kahden vuoden takainen julkaisu. Korjaus on pinnaus ja lisäosien asentaminen erikseen: pip install 'markitdown==0.1.6', ja sen jälkeen 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Tätä seurataan issue #2179 -tapauksena.
Tekevätkö MarkItDown ja OCR:n skannatuille PDF:ille?
Eivät oletusasennuksessa. Sen PDF-polku tekee vain tekstin purkua, joten pelkästä kuvasta koostuva PDF ilman tekstikerrosta palauttaa tyhjän merkkijonon — ei virhettä, ei varoitusta. OCR vaatii valinnaisen Azure Document Intelligence -taustaratkaisun tai pluginin, joista kumpikaan ei tule mukana oletuksena. Tämä on pitkään seurattu puute (issue #1268).
Kuinka hyvin MarkItDown käsittelee taulukoita?
Sisällön osalta erittäin hyvin — 13 tapauksen testissä kaikki taulukon sisältö säilyi 100-prosenttisesti. Rakenne riippuu muodosta: yksinkertaiset, leveät, otsikottomat ja tyhjiä soluja sisältävät taulukot tulevat ulos siisteinä GFM-ruudukoina, mutta rowspan ja colspan menevät rosoisiksi (ja rowspan voi siirtää dataa hiljaisesti väärään sarakkeeseen), sisäkkäiset taulukot litistyvät roskariveiksi, eikä solujen sisäisiä putkimerkkejä escapata. Markdownin litteä taulukkomuoto ei yksinkertaisesti pysty kuvaamaan spanneja tai sisäkkäisyyttä.
Onko MarkItDown tarpeeksi nopea isoille dokumenteille?
Se ei kaadu isoihin tiedostoihin, mutta varaa resursseja tyypin mukaan. 492-sivuinen PDF vei noin 3,2 minuuttia (noin 0,39 s/sivu), koska se tekee sivukohtaista lomaketunnistusta, ja on CPU-sidonnainen. 50 000 rivin taulukkolaskenta valmistui noin minuutissa mutta käytti +374 Mt RAMia, koska se rakentaa yhden suuren Markdown-merkkijonon muistiin. Suurille PDF:ille varaa minuutteja CPU-aikaa; suurille taulukoille varaa satoja megatavuja RAMia.
Kokeile Thunderbitia web-datan poimintaan Get Started Free
