对于经纪人导入管道，您会强制执行哪些不变量？
2 分•作者: julien_devv•5 个月前
我正在为零售投资组合开发一个券商导入管道，但我低估了实际中导出的数据有多么混乱。
我遇到的问题包括：
* 同一券商提供 CSV、JSON 和 PDF 格式的导出文件
* 欧盟/美国数字格式差异
* 日期在前和月份在前的歧义
* ISIN/股票代码/名称不匹配
* 重复行和部分持仓
* 解析错误悄无声息地损坏成本基准
我目前的方案是先确定性处理：
1. 在本地解析结构化导出文件
2. 仅在解析失败时使用 LLM 兜底
3. 规范化股票代码并拒绝无效行
4. 在持久化之前需要人工审核
5. 谨慎应用导入以避免成本基准偏差
我正在努力清晰地思考这个系统应该强制执行的不变量。
对于那些从事过金融导入、会计系统或安全关键数据管道工作的人：
* 你们绝对会强制执行哪些不变量？
* 你们会在哪里划分确定性逻辑和 LLM 提取的界限？
* 你们会记录哪些内容以便重放/调试/审计？
如果需要，我很乐意分享实现细节。
查看原文
I’m working on a broker import pipeline for retail portfolios, and I underestimated how messy exports are in practice.<p>Problems I’ve seen:
- CSV, JSON and PDF exports for the same broker
- EU/US number formats
- date-first vs month-first ambiguity
- ISIN/ticker/name mismatches
- duplicate rows and partial positions
- bad parses silently corrupting cost basis<p>My current approach is deterministic-first:
1. parse structured exports locally
2. only use an LLM fallback when parsing fails
3. normalize symbols and reject invalid rows
4. require human review before persistence
5. apply imports conservatively to avoid cost-basis drift<p>I’m trying to think clearly about the invariants this system should enforce.<p>For those who’ve worked on financial imports, accounting systems, or safety-critical data pipelines:
- what invariants would you absolutely enforce?
- where would you draw the boundary between deterministic logic and LLM extraction?
- what would you log for replay/debug/auditability?<p>Happy to share implementation details if useful.