Beta 阶段的发布 PQ.v.Next

视频链接包括PQ的使用以及用户的真实反馈：

https://www.bilibili.com/video/BV1oVqGBXE2p/?spm_id_from=333.1387.homepage.video_card.click

https://www.bilibili.com/video/BV1SbqGBrEK9/?spm_id_from=333.1387.homepage.video_card.click

项目地址：https://z.gitee.cn/zgca/repos/zgca/aipq/tree/feature%2FKG_test

一、对全世界 🌍「我们吹的牛，实现了」

新闻稿 · PQ.v.Next版本发布

新闻稿视频发布：https://www.bilibili.com/video/BV1SbqGBrEK9/?spm_id_from=333.1387.homepage.video_card.click

视频展示了用户从第一次使用经过Alpha阶段的提出的诸多问题，到对Beta阶段时发自内心PQ的认可，包括平常的使用以及对我们后期进一步维护的期待。真正意义上做出了对用户有帮助的产品。

我们实现了什么？

因为在 Beta 阶段，我们已经真实跑通了整条链路：

  • 从 PDF → OCR → 实体/关系抽取 → KG；
  • 从 KG + 原文上下文 → LLM 出题；
  • 从 单一题型 → 布鲁姆多层级题目；
  • 从 “重新出题” → “同知识点，不同认知层级换题”。（目前测试还未接入）

核心价值：使得用户拥有更高效地开展演讲以及提高演讲的质量，并且对于听众来讲也能够更加深入了解演讲者的演讲。

二、对投资人 💼

「我们说到做到了」——一次 Alpha → Beta 的真实验证

如果用 NABCD 来看 Beta 阶段，我们得到了什么？

N（Need）需求是否真实？

✔️ 被反复验证

  • 用户真正的痛点不是「没题」

  • 而是：

    • 题目层级单一
    • 换题=换知识点
    • 认知训练不可控

Daily Scrum 中多次提到：

“最终目标不是多出题，而是知识点不变，只改变布鲁姆层级” Daily scrum 撰写。

A（Approach）方案是否跑通？

✔️ 跑通，而且是工程化跑通

我们不是单点模型 demo，而是完整流水线：

  1. 文档 → OCR → 结构化文本
  2. NRE + LLM → 实体 / 关系修正
  3. Neo4j / KG 结构
  4. KG + 上下文 → 多层级题目生成
  5. 支持 B1 ~ B6 的切换与扩展

而且在 176 小时真实投入后，流水线完成并可复现Daily scrum 撰写。

B（Benefit）收益是否清晰？

✔️ 对用户、对平台都清晰

  • 用户：

    • 出题成本显著下降
    • 认知层级可控
    • 换题不等于推倒重来

  • PQ小程序：

    • 题目生成从“内容生产”升级为“认知建模”
    • 形成长期数据与模型壁垒

C（Competition）竞争差异？

✔️ 差异不在模型，而在认知结构

别的产品：

  • LLM → 题目

我们：

  • 知识点 → 认知层级 → 题目

这是结构性差异，不是 Prompt 优化。

D（Delivery）是否交付？

✔️ 已交付 Beta

三、对程序员 👩‍💻👨‍💻

「我们用正确的方式做软件」

如果这个项目在 Beta 阶段选择开源，一个理性的工程师首先会问的不是“牛不牛”，而是：

这是不是一个值得长期投入的系统？

我们的答案不是口号，而是工程事实。

🧱 软件工程质量的几个硬特征

1. 不是 Demo，而是完整流水线（Pipeline First）

这个项目从一开始就拒绝单点成功。

我们没有做：

  • 一个“看起来很厉害”的 LLM 出题脚本
  • 一个跑一次就结束的 Notebook

而是构建了一条可演进的流水线：

  • 输入层：PDF / 文档 → OCR → 标准化文本
  • 抽取层：实体抽取、关系抽取（NRE + LLM 修正）
  • 结构层：知识点、关系、上下文 → KG 表达
  • 认知层：布鲁姆分类作为中间表示（而不是标签）
  • 生成层：基于 KG + 上下文 + 认知层级的题目生成
  • 替换层：同一知识点，不同认知层级的题目切换

关键点在于：

  • 每一层都是可替换的
  • 每一层都有明确输入 / 输出契约
  • 每一层都可以单独测试与评估

这意味着：

你不是在维护一个 Prompt，而是在维护一个系统。

2. 真实 Scrum，而不是“写给老师看的 Scrum”

Daily Scrum 在这个项目里不是仪式，而是决策工具。

你能清楚看到：

  • 原始计划：160 小时

  • 实际投入：176 小时

  • 明确标注：

    • 哪些假设成立了
    • 哪些被推翻了
    • 哪些地方必须引入人工规则
    • 哪些地方 LLM 暂时不可控

技术债不是被隐藏，而是被记录下来：

  • 关系抽取效果一般 → 明确记录
  • 布鲁姆层级分布不均 → 明确承认
  • 纯 LLM 不可行 → 调整架构，而不是调 PPT

对程序员来说，这意味着：

这是一个允许你说“这里现在还不行”的项目，而不是逼你“看起来行”。

3. 承认 LLM 的边界，而不是对它进行宗教化崇拜

这个项目有一个非常重要、但在很多 AI 项目中缺失的原则：

LLM 是能力放大器，不是系统本身。

具体体现为：

  • 不追求“纯 LLM 自动化”
  • 不把 Prompt 当成核心资产
  • 不把“生成看起来像对的东西”当成成功

我们选择的是：

  • 规则 / 结构 / 人工约束 + LLM
  • 用 LLM 修正关系，而不是凭空生成世界观
  • 用布鲁姆分类作为认知约束，而不是事后贴标签

这对工程师来说意味着：

  • 系统是可控的
  • 行为是可解释的
  • 失败是可定位的

这不是最“性感”的 AI 方案，但是最可维护的。

4. 复杂问题被真正拆解，而不是“一句话糊过去”

在很多项目里，“出题”是一个黑箱：

文档 → AI → 题目

在这里，“出题”被拆解成了五个明确的工程问题：

  1. 抽取：

    • 什么是知识点？
    • 什么是实体？什么不是？

  2. 结构：

    • 知识点之间如何关联？
    • 哪些关系是教学上有意义的？

  3. 认知：

    • 这是记忆、理解，还是分析？
    • 认知层级是否是系统的一部分？

  4. 生成：

    • 在认知约束下生成题目，而不是事后分类

  5. 替换：

    • 同一知识点，如何在不同认知层级间切换？
    • 换题是否仍然保持教学目标一致？

这个拆解本身，就是一个成熟工程团队才会做的事情。

四、强烈结尾 🔥

「目标用户，真的喜欢吗？」

📊 Beta 阶段的真实 NPS（定性，但可信）

我们刻意没有在 Beta 阶段急着追求一个“漂亮的 NPS 数字”，
但从已有的用户反馈中，出现了一个非常一致的信号：

  • 用户愿意推荐
  • 但推荐理由和我们最初预期的不一样

他们并不是在说：

  • “这个 AI 好聪明”
  • “生成得好快”

而是在说：

“它让我第一次意识到，我以前出的题，其实只是在考记忆。”

这是一种认知层面的反馈，而不是功能层面的夸奖。

🤯 和最初想象的关键差异

我们原本以为用户会喜欢：

  • AI
  • 自动化
  • 效率提升

但真正让他们留下来的，是：

  • 被迫面对认知层级的现实
  • 终于可以‘换题而不换知识’
  • 教学设计不再是经验活，而是结构化决策

换句话说：

用户不是因为“省事”而喜欢它，
而是因为它让他们变得更专业。

posted @ 2025-12-17 17:25  Bingzheng  阅读(2)  评论(0)    收藏  举报