直播主题
- 本场聚焦古籍数字化和大模型工程落地，讨论了“繁体与生僻字识别、低预算项目、交付可行性”的真实冲突。
核心观点
- 古籍数字化不是单一 OCR 问题，而是识别、结构化、检索、解释四层问题叠加。
- 预算决定技术路线。低预算项目很难支持深度微调，必须优先采用可复用的现成能力。
- 先拆任务再提精度：先把“可识别”做出来，再迭代“高准确”和“高可解释”。
- 通用大模型在垂直稀有字符场景会失真，关键在于领域样本和检索策略，而非只换模型。
- TOB 项目最怕“目标过大+资源过小”，需求边界必须在商务阶段先对齐清楚。
高频问答
Q1：古籍里繁体字、生僻字多，直接做向量库为什么效果差？
A： 因为前置识别质量不足，错误字符进入知识库后会放大检索噪声，后续问答再强也难补救。
Q2：低预算项目能不能做大模型微调？
A： 一般不建议。更现实的路径是先做识别和检索质量基线，再按收益决定是否投入微调。
Q3：千万级文本量会不会导致检索很慢？
A： 会，若无分层索引和过滤策略，召回会变慢且噪声上升，需要做结构化拆分和检索优化。
Q4：交付时最容易踩的坑是什么？
A： 需求承诺超出预算边界。客户希望“低成本+高准确+全自动”，但实际往往无法同时满足。
实操建议
- 先定义最小可交付目标：可检索、可追溯、可人工复核，而不是一步到位“全自动高精度”。
- 古籍场景优先做字符层与版面层清洗，减少错误文本进入知识库。
- 把“识别错误”与“检索错误”分开统计，避免把所有问题都归咎于模型。
- 商务合同中明确边界：预算不含微调时，不承诺微调级效果。
- 用阶段验收替代一次性交付，先保可用，再追求高精。
延伸讨论
- 直播还讨论了算力消纳、私有部署和地方项目落地，核心共识是：先解决能稳定交付的问题，再扩展技术理想。
- 在 AI 工程里，路线正确比工具新旧更重要，错误的项目边界会消耗掉所有技术优势。