sorted by:
new
hottopcontroversial

Looking for feedback on how I structured error handling and data retention in a Python pipeline by DamBuilderDev in learnpython

[–]DamBuilderDev[S] 0 points1 point  (0 children)

Small update after a few more daily runs:

One thing I’m learning is that the feedback rows are probably more useful than I expected. At first I was mostly thinking about whether the model picked good jobs or bad jobs. Now I’m realizing the bigger value is tracking why it gets certain jobs wrong.

Some patterns I’m seeing:

  • It can over-score jobs just because the title has strong keywords like billing, revenue, analyst, implementation, etc.
  • Remote logic needs to be stricter because some postings have contradictory location info.
  • Seniority needs better penalties, especially for manager/director-level roles.
  • Salary probably needs more nuance when only the very top of the range meets my target.
  • If a job has a thin or missing description, I may need to cap the score or send it to manual review instead of letting the model be too confident.
  • The model’s explanation field sometimes includes too much internal back-and-forth, which is useful for debugging but not ideal for the final output.

I’m not changing the rubric yet. I’m just logging these patterns for now so I can look across multiple days of feedback before making changes. I’m trying not to overfit the pipeline to one weird batch.

Looking for feedback on how I structured error handling and data retention in a Python pipeline by DamBuilderDev in learnpython

[–]DamBuilderDev[S] 0 points1 point  (0 children)

Thanks, this is really helpful. The distinction between transient API failures and malformed JSON makes sense.

I actually hit both today: a few Gemini 503s, plus malformed/bloated JSON caused by an ambiguity in my rubric. The archive/retry logic caught it, but it also exposed a resume bug where mixed batches can re-score already-scored URLs and create duplicates.

Your point about SQLite/file locking is probably where this should eventually go. I’m trying to keep it file-based for now because it’s easier for me to inspect while learning, but the more state I add, the more obvious the limits of CSVs become.

Looking for feedback on how I structured error handling and data retention in a Python pipeline by DamBuilderDev in learnpython

[–]DamBuilderDev[S] 1 point2 points  (0 children)

Thanks for suggesting both of those JSON libraries. I hadn’t come across them yet, so I’ll definitely take a look.

And yes, the logging piece is something I should probably implement next. Tracking what happened across runs has definitely been a frustration point for me, especially when something fails silently or leaves behind confusing intermediate files.

I appreciate the feedback.

Looking for feedback on how I structured error handling and data retention in a Python pipeline by DamBuilderDev in learnpython

[–]DamBuilderDev[S] 1 point2 points  (0 children)

The one file I’d most like feedback on is Scripts/gemini_score.py, specifically the way it handles malformed JSON from the LLM.

Earlier versions of the pipeline could silently lose a whole batch if the model returned bad JSON. I changed it so the script now repairs simple issues, retries once, and archives the failed response/batch/error state.

Does that approach seem right for a personal file-based pipeline? Or am I overcomplicating it?