内部工作稿 · 非正式结论
Internal Meeting Prototype / 2026-08-06
Zoning智能问答V2
三阶段汇报原型
从上一阶段问题诊断，到V2协议重构，再到密集测试、数据回流与双A100训练路线。
本次会议不是宣布“稳定95%”。
本次会议要决定：当前错误究竟来自Gold、检索、证据闭合、Answerer还是Judge，以及下一阶段应该训练什么。
PROTOTYPE 开场文本
“今天重点不是罗列版本和功能，而是确认三件事：上一阶段为什么没有形成可信的稳定准确率；V2针对这些原因做了什么；下一阶段如何通过密集测试形成真正可用于训练和论文的数据。”
今天必须形成的内部决定
Kaiwen
评价范围
- 论文正式样本多少城市、项目和问题？
- 哪些问题类型进入主实验？
- 扫描件是否作为独立扩展？
Gold治理
- 谁负责初审、复审和争议仲裁？
- 何种状态才能进入准确率分母？
- 如何保证项目年代与法规版本匹配？
训练对象
- 先跑无训练Qwen基线还是立即LoRA？
- 优先训练Retriever、Answerer还是Judge？
- 哪些失败样本允许回流训练？
实验环境
- 双A100节点如何通过Tailscale接入？
- 代码、原件、运行产物和Gold分别放哪里？
- 如何断点续跑并统计GPU时间与Token？
如果会上没有决定“接下来训练什么、用什么数据训练、怎样证明训练有效”，这次汇报就还没有完成。
PROTOTYPE 讲稿
“我们希望会议结束时，不只是知道系统长什么样，而是锁定正式测试口径、Gold复核机制、服务器运行方式和第一轮训练路线。”
整场汇报的三阶段主线
Kaiwen
阶段一 · 问题诊断上一阶段为什么出现正确但不完整、D/E表现不稳定、Gold和Judge难以信任。
→
阶段二 · V2重构建立Question/Gold、Answer/Modules、Judge/Evaluation三条独立链路。
→
阶段三 · 密集测试通过分层盲测定位错误，把不同错误回流给真正负责的模块。
01
为什么没有过关
不是单纯模型不够大，而是答案闭合、Gold、检索、Judge和复现协议共同存在问题。
02
我们改了什么
把出题、答题和判题分开，并以Artifact、Schema和hash建立可追踪关系。
03
如何决定训练
先收集错误分布，再判断是训练检索器、Answerer，还是只需修协议和Gate。
PROTOTYPE 过渡文本
“第一阶段回答为什么改；第二阶段回答改成什么；第三阶段回答怎样证明改对了，以及数据如何转化为下一轮训练资产。”
STAGE 01 / PROBLEM DIAGNOSIS
上一阶段的问题与原因
我们能够找到并正确回答部分法规事实，但尚未证明系统可以跨城市稳定、完整地回答审批问题。
Coverage闭合失败
D/E全局排序局限
Gold、Judge与成本问题
上一阶段：链路跑通，不等于性能稳定
Kaiwen
当前可以声明“完整评测闭环已经能够运行”，但不能声明“系统已经稳定达到95%以上”。
已经得到的
- 真实项目与法规输入
- Module 1-4产物
- A-F六组证据包
- Answerer与Primary Judge
- 五项指标与HTML报告
尚未证明的
- 跨城市稳定性
- 复杂问题全部槽位闭合
- Gold普遍可靠
- 外部封存盲测泛化
- 审批项目无人复核可用
准确表述：部分先导案例表现较好，当前主要成果是研究方法与评测工程成立，而不是已经获得稳定跨城市准确率。
待补图表：Fremont和Livermore各放一张结果摘要卡，但标注Pilot、版本、问题数和Gold复核状态。
PROTOTYPE 讲稿
“上一阶段最重要的收获不是一个百分比，而是我们发现了平均准确率会掩盖哪些失败。接下来先从Coverage问题开始。”
核心症状：Correctness高，但Coverage低
Kefan
Correctness已经写出来的事实是否正确。
Coverage问题要求的required items是否全部回答。
典型失败：7项写出的事实全部正确，但问题要求15项，因此答案仍然不完整。
复杂开发问题
├─ use
├─ height
├─ FAR
├─ front setback
├─ side setback
├─ parking
├─ measurement
├─ applicability
└─ exceptions
全局 Top-k
└─ 多条相似 height 证据
└─ 其他槽位被挤出
上一阶段不是“答案大量错误”，而是“模型不知道还有哪些项目没有回答”。
PROTOTYPE 讲稿
“因此不能只看模型写出的句子是否正确。审批问题要求的是关键义务全部闭合，缺一项就可能改变项目判断。”
D/E为什么没有自然解决Coverage
Kefan
D · 法律优先级
Module 3能够找到法律上重要的条文，但“重要”不等于“与当前问题相关”。
- 定义、适用范围可能排名很高
- 具体高度或停车条文可能靠后
- D适合作为消融，不适合独立生产答案
E · 固定权重融合
0.75 relevance + 0.25 priority仍然生成一个全局排行榜。
- 多个槽位竞争同一Top-k
- 重复条文挤占候选位置
- 扩大Top 20到Top 120仍不保证每槽覆盖
问题同时要求高度、FAR、退界、停车和例外
→
全局排序所有条文使用一个分数
→
候选拥挤相似条文占据多个位置
→
结果部分required item没有证据
D/E的问题不只是权重，而是排序单位不对：应从整题全局Top-k转向逐槽检索与闭合。
待补：一张真实问题的Top 20或Top 120排名，标出重复条文和缺失required item。
Gold、Judge、耗时与复现同样存在问题
Xuechun Kefan Kaiwen
Gold风险
- 从不完整检索结果生成Gold
- 问题先于答案，required items遗漏
- 项目年代与法规版本不匹配
- Candidate未过证据门却被误当正式Gold
Judge风险
- Schema或标签不合法
- 本地检查被误读为语义Judge
- N/A、0分和协议失败混淆
- Correctness被误读为整体准确率
成本风险
- PDF与完整CSV反复读取
- 失败后从头运行
- Answerer和Judge上下文过长
- 模块时间与模型时间未分开
复现风险
- 历史版本与现役程序混杂
- 源码、原件、Gold、运行产物混放
- 城市报告命名冲突
- 无法确认某一分数对应哪次运行
PROTOTYPE 讲稿
“如果Gold、Answer、Judge和运行版本没有清晰边界，再高的百分比也无法进入论文。因此V2首先修复的是研究协议，而不是继续堆模型调用。”
阶段一结论：问题发生在整条链路
Kaiwen
| 失败现象 | 更可能的原因 | 不能直接采取的错误做法 |
|---|
| Gold自身漏项 | 来源、版本或事实核对不完整 | 直接用更多Answerer调用“补正确” |
| 证据未进入候选集 | Module 2召回与全局Top-k | 只训练Answerer记住答案 |
| 证据齐全但回答漏项 | Answerer或槽位闭合 | 继续无上限扩大检索文本 |
| 适用条款判断错误 | Module 3/4法律角色与Gate | 只调相关性权重 |
| Judge与人工不一致 | Judge合同、标签或Gold争议 | 直接用Judge输出训练Judge |
诊断原则：先定位错误属于数据、检索、证据闭合、生成还是评价，再决定是否训练模型。
V2的任务，是把每一种错误送回真正负责的环节，而不是让一个更大的LLM掩盖所有问题。
PROTOTYPE 过渡文本
“基于这一诊断，第二阶段介绍V2具体如何重新划分职责、隔离数据和建立协议。”
STAGE 02 / V2 RESTRUCTURING
V2做了什么架构调整
把出题、答题和判题拆成三条权责独立、可验证、可复现的链路。
三类数据与三业务域
Gold-Question协议与防泄漏
逐槽检索、A-F与独立Judge
V2总体架构：出题、答题、判题分离
Kaiwen
01 Question / Gold
确定考什么，以及完整标准答案是什么。
- Fact Extractor
- Gold Legal Crosswalk
- Gold Builder
- Question Generator
02 Answer / Modules
在不知道Gold的条件下寻找法规并回答。
- Module 1-4
- Slot Router
- Fusion
- Answerer
03 Judge / Evaluation
在答案冻结后使用封存Gold进行评价。
- A-F Evidence Packs
- Primary Judge
- Metric Compiler
- HTML Report
Question/Gold作者侧私有研究链路
→
Answer公开问题＋法规，Gold-blind
→
JudgeAnswer hash冻结后读取Gold
错误可以分别定位到Question/Gold、Answer/Modules或Judge/Evaluation，而不再混成一个“模型准确率”。
待插图：使用现有V2中文架构图的精简版本，只保留三业务域和Artifact流向。
V2使用的三类公开研究数据
Kaiwen
城市法规
Zoning Code、district regulations、overlay、停车、定义和交叉章节。
作用：Answer生产链路的法律回答依据。
项目报批材料
Development application、project narrative、site plan、waiver request。
作用：提供真实项目场景和开发商问题。
政府审查与审批
Staff Report、findings、conditions of approval、resolution。
作用：核验主管部门实际采用的法规和条件。
workspace/projects/<project_id>/inputs/files/
├─ zoning document/ 法规生产依据
├─ project document/ 项目场景与事实
└─ government approval/ Gold外部核验
隔离原则：Gold/Question链路可读取三类材料；Answerer只能读取Question和法规，不得读取审批结果或Gold。
PROTOTYPE 讲稿“法规说明一般规则，报批材料说明申请人提出什么，审批材料说明主管部门如何处理。三者用途不同，不能混成同一个Answer上下文。”
Answer-First Gold与A-F实验资格
Xuechun
项目/审批材料提取已确认项目事实
→
法规Crosswalk核对年代、章节、页码、条件
→
GoldSpecrequired items与证据
→
QuestionSpec根据可回答范围生成问题
Gold进入正式评价前
- 值、单位、条件和例外齐全
- 项目年代与法规版本匹配
- 章节、页码、原文、chunk ID和hash可追踪
- 人工复核状态明确
以下样本不得进入分母
- 只有Gold Candidate
- 法规证据不闭合
- 项目事实与法规无法对照
- Gold与Question槽位不一致
A-F资格：只有问题、Gold、法规版本和证据范围冻结后，才可以运行完整A-F。
待插入：雪纯准备一份真实Gold卡片，显示required item、法规证据、项目证据和review status。
Gold Generator与Question Generator协议层
Kaiwen
GoldSpec · Judge私有
- gold_id / question_id / task_type
- required_items与expected values
- 适用条件和例外
- 法规与项目证据
- source hash与review status
QuestionSpec · Answerer可见
- question_id / task_type
- jurisdiction与district
- building type与scenario
- requested dimensions
- 自然语言问题，不含标准值
Fact Ledger共享私有事实层
→
Question-Gold Link Receipt只保存一一对应关系与hash
→
Release Boundary只向Answerer释放QuestionSpec
防泄漏：问题文本、Answerer参数、环境变量、工作目录和证据包中不得出现Gold值、期望章节或私有Judge路径。
PROTOTYPE 讲稿“雪纯负责Gold内容是否完整，我负责Gold和Question之间如何配对、冻结和隔离。Question Generator可以在作者侧知道事实范围，但输出不得泄漏答案。”
Module 2与Module 4：从排序转向证据闭合
Kefan
Module 2 · 逐槽召回
- 每个required slot独立检索
- Domain-BGE主排序
- BM25保底与cross-reference resolver
- 保留query、候选、分数与hash轨迹
- 槽位配额满足后再跨槽去重
Module 4 · 证据Gate
- 输出covered与missing slots
- 检查citation和applicability冲突
- 只对缺失槽位定向补检索
- 至多一次Gold-blind repair
- 不足时CONDITIONAL/NEEDS_REVIEW/INCOMPLETE
Question slotsheight / FAR / parking / exception
→
Slot retrieval每槽独立候选
→
Evidence gate检查是否闭合
→
Answer permission通过、条件化或拒答
待插入：可凡提供一个旧全局Top-k与新逐槽候选的前后对照，以及一个Module 4 false PASS案例。
A-F与Judge：生产复用，评价隔离
Xuechun Kefan
| 组 | Answerer获得的证据 | 研究目的 |
|---|
| A | 完整PDF | 全文Agent基线 |
| B | Module 1完整结构化全文 | 结构化是否损失信息 |
| C | Module 2相关性证据 | 检索相关性效果 |
| D | Module 3法律优先级证据 | 法律优先级消融 |
| E | Module 2与3融合证据 | 融合检索效果 |
| F | Module 4最终证据与Gate | 完整生产链路 |
复用原则：Module 1-4只运行一次并冻结；A-F从同一批产物编译证据包。分别运行的是12次Gold-blind Answerer和6次Primary Judge。
Answerer
每组2次独立回答，保存模型参数、耗时、Token和answer hash。
Judge
Answer冻结后读取Gold，逐required item裁决。
Metrics
Correctness、Coverage、Faithfulness、Uncertainty F1、Consistency。
文件、环境与合规边界
Kaiwen
GitHub
代码 / Schema / Protocol / Skill / Tests
Google Drive
法规 / 报批 / 审批原件 / 研究清单
V2_RUNTIME
Module产物 / A-F包 / Answer / Judge / HTML
Private Gold
Gold / 人工复核 / Answer hashes
复现边界
- 原件以来源链接、访问日期和hash定位
- 运行产物不进入Git
- 每个run有唯一ID和manifest
- 报告显示版本、模型和调用回执
合规边界
- 材料来自政府公开档案
- 版权仍归原权利人
- 不重新分发或销售原始文件
- 论文提供有限引文、链接、hash与派生数据
公开访问不等于版权转移；可复现也不要求我们重新托管所有第三方PDF。
PROTOTYPE 讲稿“GitHub保存程序，Drive保存研究原件，V2_RUNTIME保存运行产物，Gold保持私有。这样既减少Agent上下文，也让研究链路可审计。”
STAGE 03 / DENSE TESTING & FEEDBACK
下一阶段密集测试与数据回流
先建立真实跨城市基线，再根据错误归因决定训练Retriever、Answerer还是Judge。
三轮分层盲测
三人协作与Artifact交接
双A100、Qwen与训练数据回流
三轮测试：从协议稳定到外部盲测
Kaiwen
01
协议稳定性
5城 × 2项目 × 2问题 = 20题。
- A-F全跑
- 每组重复2次
- 修Schema、N/A、hash和回执
- 不宣称稳定准确率
02
跨城市基线
20城 × 2项目 × 2问题 = 80题。
- 覆盖不同法规结构
- 简单题＋条件触发题
- 统计城市间方差
- 判断瓶颈属于哪一层
03
封存外部盲测
使用未参与调参的新城市和项目。
- Gold提前封存
- 不针对单题修提示词
- Answer后置Judge
- 作为论文主要结果
正式声明原则：只有第三轮完成后，才讨论跨城市性能、置信区间和是否达到预设门槛。
待团队决定：第二轮是否所有80题完整跑A-F，还是先对A/E/F全量、C/D做分层抽样。
密集测试中的三人分工
全组
Xuechun · Gold与A-F
- 筛选项目与审批材料
- Fact Ledger与Gold
- Question/Gold配对资格
- required items与法规版本
- A-F研究定义与人工复核状态
Kefan · M2/M4与指标
- 检索候选与排序轨迹
- required item-evidence mapping
- Module 4 Gate与缺项
- Judge标签和五项指标
- 错误分类与前后对照
Kaiwen · 协议与基础设施
- GitHub/Drive/V2_RUNTIME
- Question-Gold协议与冻结
- Tailscale/A100/Qwen
- 批次调度、耗时和Token
- HTML、Dashboard与复现包
共同职责：任何人发现Gold、法规版本或证据冲突，先隔离样本，不得为了保持分数而临时改判。
PROTOTYPE 讲稿“分工按责任域划分，但所有人使用同一QuestionSpec、GoldSpec、Artifact和错误分类表，避免三套口径。”
失败数据如何回流
全组
测试失败保留run、evidence、answer和judge回执
→
错误分类Gold / Question / Retrieval / Gate / Answer / Judge
→
定向回流送回真正负责的模块
| 错误类型 | 回流内容 | 处理方式 |
|---|
| Gold错误 | 来源、版本、事实或required item争议 | 隔离样本，重新核对；不进入训练 |
| Question错误 | 含糊问题、Gold槽位不一致 | 修Question Generator协议与反例集 |
| Retrieval错误 | query-positive chunk、hard negative、错误排名 | Module 2调参或Retriever/Reranker训练 |
| Gate错误 | missing slot、false PASS、citation gap | 修Module 4规则与repair策略 |
| Answerer错误 | 证据齐全但漏项、错单位、错引用 | 形成Qwen结构化Answer SFT样本 |
| Judge错误 | 人工与Judge不一致 | 进入争议集，人工仲裁后再校准 |
数据回流不是把所有失败塞进模型，而是让每一种失败返回真正负责的环节。
下一阶段训练路线：先基线，后定向训练
Kaiwen
阶段0 · 无训练Qwen基线
- 固定模型、温度、Schema和提示词
- 运行A-F与重复实验
- 统计真实错误分布、速度和显存
- 确认问题到底在检索还是生成
阶段1 · Retriever/Reranker
触发条件：Gold证据存在，但经常进不了候选集。
- question-evidence正样本
- required item-chunk配对
- hard negatives
- 跨引用解析
阶段2 · Answerer LoRA/SFT
触发条件：证据已经齐全，但回答仍漏项或格式错误。
- Evidence Pack到结构化Answer
- 槽位闭合和单位
- 引用对齐
- 不确定性表达
阶段3 · Judge校准
触发条件：人工复核与Judge系统性不一致。
- 先统一标签口径
- 建立双人仲裁样本
- 再考虑Judge微调
- 避免循环训练污染
推荐：下一阶段先部署Qwen推理基线，不立即全参数训练；根据20-80题的错误分布决定训练对象。
Tailscale＋双A100测试环境
Kaiwen · Placeholder
组员电脑
│
└─ Tailscale 私有网络
│
▼
双 A100 40GB Linux 节点
├─ GitHub 代码同步
├─ Qwen 模型服务
├─ Module 1-4 批处理
├─ A-F Answerer 任务队列
├─ V2_RUNTIME / model cache
├─ checkpoint / manifest / answer hash
└─ GPU 时间 / Token / 错误日志
│
▼
Google Drive
├─ 输入原件与项目清单
├─ 冻结无 Gold 答案包
└─ 批次结果与报告
待确认技术项
- Qwen具体型号和量化
- vLLM、SGLang、Ollama或Hermes
- 张量并行还是任务并行
- 上下文长度与并发数
- Drive同步与断点续跑
安全与边界
- 不暴露公网端口
- 只允许Tailnet设备访问
- 密钥只留服务器
- Gold与Answer分目录
- 原始PDF不进入GitHub
本页明确保留Placeholder标记；服务器尚未实测前，不写吞吐量、显存占用或单题耗时结论。
里程碑、回流纪律与会议结论
Kaiwen
M1 · 协议稳定
完成5城20题，消除Schema、Gold泄漏、N/A和回执问题。
M2 · 跨城基线
完成20城80题，报告每类错误、城市方差、时间和成本。
M3 · 训练与封存测试
根据错误归因训练指定模块，并用未参与调参的新城市验证。
数据纪律：按城市或项目划分Training、Validation和Sealed Test。测试案例一旦用于调参，就必须退出封存测试集。
我们的目标不是把所有错误交给一个更大的模型，而是建立一条可以解释“哪个改动改善了哪个指标、付出了多少成本”的研究链路。
PROTOTYPE 结束文本
“建议本次会议锁定第一轮5城20题、Gold复核责任、Qwen无训练基线和Tailscale服务器接入。完成协议稳定性后，再依据真实错误分布决定是否训练Retriever、Answerer或Judge。”
会议现场填写：正式样本量 / Gold复核人 / 第一批城市 / A100负责人 / Qwen型号 / 首轮完成日期。
← MonkeyHub Institute · People