-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ITN runtime. #2001
ITN runtime. #2001
Conversation
Great job! Please fix the lint problem. |
感谢!晚会看一下 |
我个人建议,能不能用sub project的方式把wetext的runtime部分引入进来呢?现在相当于把wetext的runtime的代码copy过来了,如果wetext有修改runtime,这边还得同步,@robin1001 觉得呢 |
把wetext当成一个subproject引入可以参考我之前的实现 : main...xcsong-wetextprocessing |
对,更建议用这种方式。以第三方库的形式集成进来。 |
openfst 我们可以直接升级,这块应该没有什么风险。 |
… both have utils and utils/string.h
今天试了一下,目前以第三方库引入之后,构建过程中,由于wenet和wetext都包含一个utils/string.h,且在引用这个头文件时都是用了“#include utils/string.h"去导入,导致两个库同时构建时,就会出现其中一个库找不到其名称空间下的utils/string.h中的方法的问题(https://github.com/duj12/wenet/blob/itn-wetext-sub/runtime/core/cmake/wetextprocessing.cmake#L25 这里会遇到构建.o时找不到wetext中的string.h的问题)。这是个fatal的issue,不改动wenet或wetext源码就无法解决。 关于这个问题,你和震东可以想想有啥好的办法解决,最简单的办法就是把wetext中的utils/string.h改个名字。 |
@xingchensong 目前这个部分的代码是我之前很早就拷贝的,有些函数方法名称还没有同步到最新的大写字母开头的那个版本上。然后命名空间改了一下,直接复用了utils模块,同时改了一下代码以便通过cpp-lint和clang-format的检测。 |
@xingchensong 帮忙看一下 |
sorry,miss掉了才看到 |
wetext 已完成文件更名:wenet-e2e/WeTextProcessing#111 |
use wetext subproject.
@xingchensong subproject的方式集成已经完成了,现在的编译方式就是,只要ITN选项打开,就会直接把wetext_processor编到wenet库里面。没有加额外的宏。 |
great ,感谢!!! |
@@ -140,7 +140,7 @@ class AsrDecoder { | |||
std::shared_ptr<PostProcessor> post_processor_; | |||
std::shared_ptr<ContextGraph> context_graph_; | |||
|
|||
std::shared_ptr<fst::Fst<fst::StdArc>> fst_ = nullptr; | |||
std::shared_ptr<fst::VectorFst<fst::StdArc>> fst_ = nullptr; | |||
// output symbol table | |||
std::shared_ptr<fst::SymbolTable> symbol_table_; | |||
// e2e unit symbol table |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update: 原来1.6.5的openfst使用fst::Fst读取,为了wetext更新到1.7.2的openfst后,需要改成fst::VectorFst
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
潜在问题纪录:recipe中的make_tlg.sh中构图所使用的fstcompile,不能是wenet自带的 https://github.com/kkm000/openfst/archive/refs/tags/win/1.7.2.1.tar.gz (为了适配windows做了一些修改),而需要官方原版openfst,http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.7.2.tar.gz
该问题仅针对构图过程存在,构图使用原版1.7.2, 推理时使用kkm000版1.7.2,是可以正常推理的
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: 需要在recipe中添加相关的提醒 OR 用patch方式修复一下kkm000的openfst?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@duj12 @pengzhendong @robin1001 any ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
原版和 kkm 区别是?打什么样的 patch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
原本的策略是linux和win用不同的openfst(win用kkm,linux用mjansche)后来在这个pr 里,统一用kkm了b59ca15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potential problem log: fstcompile used in the composition of the make_tlg.sh in the recipe cannot be the https://github.com/kkm000/openfst/archive/refs/tags/win/1.7.2.1.tar.gz that comes with Wenet (some modifications have been made to adapt to Windows), And you need the official original openfst, http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.7.2.tar.gz
This problem only exists for the composition process, the original version 1.7.2 is used for composition, and the kkm000 version 1.7.2 is used for inference, which can be reasoned normally
I tried to use http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.7.2.tar.gz, but it's not work, I had an error fst
@duj12 大佬,这样加ITN的话,word_pieces的字、时间戳和ITN之后的是不是不一致了 |
The fst-based ITN model is compiled from WeTextProcessing,
I made a version of mine, which solve some known corner cases. You can download it from ModelScope
For now, decoder_main and api_main(Both with libtorch backend) is validated after ITN is added.
Other runtime may still have some issue.
For decoder_main, the running command and result is like:
For api_main, the running command and result is like:
In this ITN runtime code, It's worth noting that the version of openfst is upgraded from 1.6.5 to 1.7.2.
So when building TLG.fst, you'd better use the same version of openfst(At least for now, the official verison of openfst in KALDI is 1.7.2(https://github.com/kaldi-asr/kaldi/blob/master/tools/Makefile#L10)).
And make sure the version of pynini in WeTextProcessing is proper(For now, the itn model compile from WeTextProcessing==0.1.1 can run successfully.)
On this version, the N-gram Language model(I have not verify the TLG.fst released by WeNet yet, but I suppose it will work) and ITN model can both work.