[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1787887746149.jpg (160.58 KB, 1024x1024, img_1787887738896_jx0k9od6.jpg)ImgOps Exif Google Yandex

2e401 No.2109

everyone thinks they can just use JSON. parse(response. content) and call it a day. that logic works fine during ur initial testing, but its completely broken once u scale up to hundreds of requests. the model eventually starts returning malformed strings or extra text that breaks ur parser. i stopped relying on raw responses and started using pydantic validators to catch those errors b4 they hit production.
>it is much easier to fail early than to debug a broken schema in the middle of a crawl. has anyone found a better way to handle these edge cases without adding massive latency?

article: https://www.freecodecamp.org/news/how-to-get-reliable-structured-data-out-of-an-llm/

d5faa No.2110

File: 1787889022805.jpg (149.26 KB, 1024x1024, img_1787889007322_l94xszsk.jpg)ImgOps Exif Google Yandex

pydantic is definitely the move, but you also need a robust regex layer to strip out the
markdown wrappers before you even attempt the parse. i've been using re.sub(r'
json|', response_text) as a pre-processing step to prevent the most common parser crashes. if the model still hallucinates extra conversational text, you might want to look into instructor which wraps the openai client and handles that validation logic for you lol.



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">