Rasa message topic classification #385
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
new version
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to c26730d in 10 minutes and 44 seconds. Click for details.
- Reviewed
4647lines of code in91files - Skipped
6files when reviewing. - Skipped posting
26draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. problem-solver/cxx/message-classification-module/classifier/RasaMessageTopicClassifier.cpp:35
- Draft comment:
Robustness note: Using .at("name") on the intent JSON may throw if the key is missing. Consider checking existence or using safer access. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 40% vs. threshold = 50% The comment points out a legitimate inconsistency. Line 115 ingetMessageIntent()uses try-catch when accessing the same JSON structure, but line 35 doesn't. This suggests the author is aware that the JSON might not have these keys. However, I need to consider: (1) Is this about changed code? Yes, this is a new file. (2) Is the issue already resolved? No, line 35 has no error handling. (3) Is this actionable? Yes, the author could add error handling. (4) But wait - maybe the code at line 35 is intentionally allowing exceptions to propagate? Looking at the function signature,classifyMessagereturnsScAddrVectorand doesn't seem to have exception specifications. The inconsistency is concerning though. Perhaps the code at line 35 intentionally allows exceptions to propagate to the caller, while line 115 handles it locally because it has different error handling requirements (returns empty string). The comment might be overly cautious if the exception behavior is intentional. Also, I should consider whether this is an "obvious" issue that doesn't need commenting. While the exception might be intentional, the inconsistency between line 35 and line 115 suggests this is worth pointing out. The comment is actionable - it suggests either adding error handling or at least being consistent. This isn't obvious because the code shows the author does handle this elsewhere, so it's unclear if line 35 is an oversight or intentional. The comment identifies a legitimate inconsistency in error handling between line 35 and line 115. However, it's somewhat speculative ("may throw") and doesn't clearly indicate what action should be taken. The comment could be more actionable, but it does point to a real code quality issue about inconsistent error handling patterns.
2. problem-solver/cxx/message-classification-module/classifier/WitMessageTopicClassifier.cpp:89
- Draft comment:
Logging formatting: The call to logger->Debug(... ) passes multiple arguments. Ensure the logger API supports variadic parameters or concatenate strings explicitly. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. problem-solver/cxx/message-reply-module/agent/MessageReplyAgent.cpp:81
- Draft comment:
Connector erasure: When the reply message formation fails, the code erases an element from the iterator. Ensure that this cleanup doesn’t remove intended data when multiple connectors exist. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. problem-solver/cxx/message-classification-module/rasa_classifier_model/actions/actions.py:16
- Draft comment:
Action implementation: The custom action simply replaces one string with another. Verify that this is sufficient for all intended cases and consider edge cases (e.g. case sensitivity). - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
5. problem-solver/cxx/message-classification-module/rasa_classifier_model/components/replacement_component.py:18
- Draft comment:
Robustness: Consider adding error handling if 'data/replacements.yml' is missing or malformed. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
6. docs/agents/messageTopicClassificationAgent.md:21
- Draft comment:
Typographical error: The phrase 'Also Wit.ai it has' contains an extraneous 'it'. Consider revising it to 'Also, Wit.ai has' for clarity. - Reason this comment was not posted:
Marked as duplicate.
7. docs/agents/messageTopicClassificationAgent.md:98
- Draft comment:
Typographical note: Please add a space betweenSC_RESULT_ERRORand the hyphen for consistency with the previous bullet. Consider changing to: *SC_RESULT_ERROR- internal error. - Reason this comment was not posted:
Comment was on unchanged code.
8. docs/agents/messageTopicClassificationAgent.ru.md:21
- Draft comment:
Typo: There is a missing space before the parenthesis in "сообщений(Rasa)". Consider revising it to "сообщений (Rasa)". Also, "Интернет соединения" could be hyphenated as "интернет-соединения" for improved clarity. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The rules state "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." This is a documentation file, not code. The comment is about minor formatting/style issues (spacing and hyphenation). While technically correct, these are very minor stylistic issues in documentation. The rules emphasize not making obvious or unimportant comments. Typos in documentation might be considered minor, especially spacing issues. However, the rules don't explicitly say to ignore documentation improvements. But the emphasis is on "code change required" and avoiding obvious/unimportant comments. This seems like a minor stylistic preference rather than a critical issue. This is documentation, not code, and improving documentation quality could be valuable. The spacing issue is objectively a formatting error in Russian typography, and the hyphenation suggestion follows Russian language conventions. These could improve the professional quality of the documentation. While documentation quality matters, the rules emphasize not making obvious or unimportant comments. These are very minor formatting issues that don't affect comprehension or functionality. The rules say "Do NOT make comments that are obvious or unimportant" - fixing spacing around parentheses is quite minor and obvious once pointed out. This comment addresses minor formatting/style issues in documentation rather than substantive code problems. While technically correct, these are minor and fall under "obvious or unimportant" comments that should be avoided per the rules. The comment should be deleted.
9. docs/agents/messageTopicClassificationAgent.ru.md:57
- Draft comment:
Typo: "формализованна" appears to be misspelled. It should be corrected to "формализована". - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
10. docs/agents/messageTopicClassificationAgent.ru.md:97
- Draft comment:
Typographical issue: There's a missing space between the inline code (SC_RESULT_ERROR) and the hyphen. Consider changing to "*SC_RESULT_ERROR- внутренняя ошибка." to be consistent with the formatting in the previous bullet point. - Reason this comment was not posted:
Comment was on unchanged code.
11. docs/agents/rasaMessageTopicClassificationAgent.ru.md:63
- Draft comment:
Typographical error: "формализованна" should be corrected to "формализована". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 35% vs. threshold = 50% This is a straightforward typo correction in documentation. The rules state "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." However, this is documentation, not code. The rules also mention that "Comments that suggest code quality refactors are good! But only if they are actionable and clear." A typo fix is actionable and clear. The question is whether fixing a typo in documentation counts as important enough. The rules seem focused on code logic rather than documentation quality. Typos in documentation could be considered minor/obvious issues that don't require a comment. On the other hand, documentation quality matters, and this is a legitimate error that should be fixed. The rules emphasize not making "obvious or unimportant" comments. A single-letter typo in documentation might be considered minor and obvious. Additionally, the rules focus heavily on code logic issues rather than documentation proofreading. This could be seen as too trivial to warrant a review comment. While typos might seem minor, documentation quality is important for professional projects, especially in technical documentation. The comment is actionable, clear, and correct. It's not speculative or asking for confirmation - it's a definitive correction. However, given the strong emphasis in the rules on avoiding obvious/unimportant comments and the focus on code logic over documentation proofreading, this falls into a gray area. This is a legitimate typo correction in documentation. While it's actionable and correct, the rules emphasize avoiding obvious or unimportant comments, and a single typo in documentation could be considered minor. Given the instruction to err on the side of deleting comments when unsure, and the focus on code logic over documentation proofreading, I'll give this a moderate-low score.
12. knowledge-base/non_subject_domain_concepts/rasa/concept_rasa_entity.scs:28
- Draft comment:
There's a trailing whitespace after the colon in the '-> rrel_example:' label. Please remove the extra space to maintain consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a whitespace/formatting issue. The comment is technically correct - there is a trailing space on line 28 that's not present on line 22. However, I need to consider whether this is "obvious or unimportant" or if it would be "obviously caught by the build". Trailing whitespace is often a minor style issue. Many linters would catch this automatically. The rules say "Do NOT make comments that are obvious or unimportant." Trailing whitespace is typically a very minor issue. However, the rules also say "Code should be DRY" and to maintain consistency, which this comment addresses. This is a borderline case - it's about consistency within the file, but it's also a very minor formatting issue that linters typically handle. This could be caught by automated linters or formatters, making it potentially too minor to warrant a manual comment. The inconsistency is very subtle and may not affect functionality at all. It might fall under "obvious or unimportant" comments that should be avoided. While linters could catch this, the comment does point out a real inconsistency in the code that was just added. However, trailing whitespace is typically such a minor issue that it falls into the "unimportant" category, especially since it doesn't affect code behavior and would likely be caught by pre-commit hooks or linters if the project uses them. This comment is about a very minor formatting issue (trailing whitespace) that is typically handled by automated tools. While technically correct, it falls into the category of "unimportant" comments that should not be made according to the review rules. I should delete this comment.
13. knowledge-base/section_subject_domain_of_actions_and_tasks/concepts/action_rasa_message_topic_classification.scs:17
- Draft comment:
Typographical: There appears to be an extraneous tab character between 'lang_ru;;' and '*);;'. Consider replacing it with a standard space for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a comment about whitespace/formatting consistency. The rules state not to comment on things that are "obvious or unimportant." A tab vs space character is a very minor formatting issue. While code consistency is valuable, this is an extremely minor typographical issue that doesn't affect functionality. The comment is technically correct (there does appear to be extra whitespace), but it's borderline whether this rises to the level of importance to warrant a comment. However, the rules do say "Code should be DRY" and to use consistent patterns, which could extend to formatting. But this seems like something a linter would catch, not a human reviewer. This could be a legitimate consistency issue if the codebase has strict formatting standards. The comment is specific and actionable. It's not speculative or asking for confirmation - it's pointing out an actual inconsistency in the code. While the comment is technically correct and actionable, it falls into the category of "obvious or unimportant" issues. This is a trivial whitespace issue that doesn't affect functionality and would typically be caught by automated formatting tools. The rules explicitly say not to make comments that are "obvious or unimportant." This comment should be deleted. While it identifies a real formatting inconsistency, it's too minor and trivial to warrant a human review comment. This type of issue should be handled by automated linters or formatters, not manual code review.
14. knowledge-base/section_subject_domain_of_intelligent_study_systems/concepts/instances/nika_docs/lab_workshop/lab_workshop.scs:22
- Draft comment:
Typo/consistency issue: In the nrel_idtf block, the text reads "Лабораторная работа 1. ..." whereas elsewhere (e.g., in the nrel_main_idtf and nrel_rasa_idtf blocks) it uses "Лабораторная работа №1". Please confirm if the omission of the '№' symbol and the period placement is intentional. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment violates the rule "Do NOT ask the PR author to confirm their intention, to explain, to double-check things, to ensure the behavior is intended". The comment explicitly says "Please confirm if the omission of the '№' symbol and the period placement is intentional." This is exactly the type of comment we should remove. The author made a deliberate change from "№1." to "1." and the comment is just asking them to confirm it was intentional, rather than identifying a clear bug or issue. Could this be a legitimate consistency issue where different identifiers should match? Perhaps there's a semantic reason why nrel_idtf should use the same format as nrel_main_idtf and nrel_rasa_idtf? While consistency could be valuable, the comment doesn't make a strong case for why these must be consistent. Different identifier types (nrel_main_idtf vs nrel_idtf) might intentionally use different formats - one is a short identifier and the other is a long descriptive identifier. The comment is phrased as asking for confirmation rather than stating a clear requirement, which violates the rules. This comment should be deleted because it asks the author to confirm their intention rather than identifying a clear code issue. The author deliberately changed the format, and without strong evidence that this is wrong, we should assume it was intentional.
15. knowledge-base/section_subject_domain_of_ostis_system_interfaces/concepts/concept_header.scs:10
- Draft comment:
Typographical note: The new identifier text '[хедер]' uses Cyrillic characters (e.g. 'х') instead of the Latin 'h'. If a consistent 'header' is intended (as seen in line 7), you might want to update this to avoid potential inconsistencies. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment appears to misunderstand the structure of this file. This is clearly a multilingual knowledge base file where[хедер](Cyrillic) is the Russian identifier and[header](Latin) is the English identifier. The new line being added isnrel_rasa_idtf: [хедер], which is adding a RASA identifier in Russian. This is consistent with line 5 which already uses[хедер]as the Russian main identifier. There's no inconsistency here - it's intentional multilingual support. The comment violates the rule about not making speculative comments and asking the author to confirm their intention. Could there be a legitimate concern that the RASA identifier should use the English version instead of Russian? Perhaps there's a convention in this codebase that RASA identifiers should always be in English, which I wouldn't know without seeing other examples. Even if there were such a convention, the comment doesn't demonstrate knowledge of it - it simply speculates about "potential inconsistencies" without providing evidence. The comment asks the author to verify their intention ("you might want to update this"), which violates the rules. Without strong evidence that this is wrong, the comment should be deleted. This comment should be deleted. It misunderstands the intentional multilingual structure of the file and speculates about inconsistencies without providing evidence. The use of Cyrillic[хедер]is consistent with the existing Russian identifier on line 5, and the comment violates the rule against asking authors to confirm their intentions.
16. problem-solver/cxx/message-classification-module/classifier/RasaMessageTopicClassifier.cpp:71
- Draft comment:
Typo: The namespace prefix is duplicated. Consider changing 'ScType::ScType::ConstPermPosArc' to 'ScType::ConstPermPosArc'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This comment identifies a clear typo/bug in the code. The duplicated namespace prefixScType::ScType::is incorrect C++ syntax and would likely cause a compilation error. The comment is about code that was changed (this is a new file being added in the diff). The comment is actionable - it tells exactly what needs to be fixed and even provides a suggestion. This is not speculative, not about styling, not asking for confirmation - it's pointing out a definite error. However, I need to consider whether this would be caught by the build. The rules say "Do NOT comment on anything that would be obviously caught by the build". A duplicated namespace prefix like this would definitely cause a compilation error, so it would be caught by the build. The rule states not to comment on things that would be obviously caught by the build. A syntax error likeScType::ScType::ConstPermPosArcwould fail to compile, so this would be caught when building the code. Therefore, according to the rules, this comment should be deleted even though it correctly identifies an error. While it's true this would be caught by the build, the comment is still valuable because it identifies the exact issue and provides the fix before the author even tries to compile. However, the rules are explicit: "Do NOT comment on anything that would be obviously caught by the build, such as variable renames, file renames, or changed imports." This typo falls into that category of things that would fail compilation. Despite correctly identifying a real typo, this comment should be deleted because the duplicated namespace prefix would cause a compilation error that would be caught by the build process, and the rules explicitly state not to comment on such issues.
17. problem-solver/cxx/message-classification-module/classifier/WitMessageTopicClassifier.cpp:63
- Draft comment:
Typographical error: "messageIntentCLassElements" seems to have an irregular capitalization. Consider renaming it to "messageIntentClassElements" for consistency. - Reason this comment was not posted:
Comment was on unchanged code.
18. problem-solver/cxx/message-classification-module/classifier/WitMessageTopicClassifier.cpp:170
- Draft comment:
Typographical error: The parameter name "possibleMessageCLass" seems to contain an unintended uppercase 'L'. Consider renaming it to "possibleMessageClass" for proper consistency. - Reason this comment was not posted:
Comment was on unchanged code.
19. problem-solver/cxx/message-classification-module/classifier/WitMessageTopicClassifier.cpp:241
- Draft comment:
Typo alert: The method call on this line is getMessageEntities, but the function is defined as getMessageEntity (singular). Please verify if the correct method should be singular or plural to ensure consistency. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
20. problem-solver/cxx/message-classification-module/client/RasaClient.cpp:57
- Draft comment:
Minor issue: The file does not end with a newline. Please add a newline at the end of the file for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a very minor stylistic issue. While it's technically correct, I need to consider if this violates the rules. The rules state "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." A missing newline at the end of a file is: 1) Very minor and unimportant, 2) Would likely be caught by linters or formatters automatically, 3) Doesn't affect functionality, 4) Is a pure style issue. The comment also says "for consistency" but we don't have context about what the project's standards are. This seems like the type of trivial, unimportant comment that should be removed. Some projects do have strict coding standards that require newlines at the end of files, and this could be part of their style guide. It's also a POSIX standard that text files should end with a newline. This might not be caught by the build system and could be a legitimate style requirement. While some projects do enforce this, the rules explicitly state to not make comments that are "obvious or unimportant." A missing newline is extremely minor and doesn't require a code review comment - it should be handled by automated formatters or linters if it's important to the project. The comment doesn't point to any functional issue or code quality problem. This comment should be deleted. It's about a trivial stylistic issue (missing newline at end of file) that is unimportant and should be handled by automated tools rather than manual code review. It doesn't meet the threshold of requiring a code change that warrants a review comment.
21. problem-solver/cxx/message-classification-module/rasa_classifier_model/actions/actions.py:1
- Draft comment:
Typographical error: "This files contains your custom actions..." should be "This file contains your custom actions...". - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =50%<= threshold50%This comment points out a typographical error in the code comments or documentation. While it is not directly related to the code functionality, correcting typos can improve code readability and maintainability. However, it doesn't directly relate to the rules provided, such as DRY, security, or code complexity. It is more of a suggestion for clarity.
22. problem-solver/cxx/message-classification-module/rasa_classifier_model/actions/actions.py:4
- Draft comment:
Typographical error: "...implement these action:" should be "...implement these actions:" or "...implement this action:" (ensure subject-verb agreement and consistency with file content). - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment is pointing out a typo in a comment/documentation line. According to the rules, I should not comment on things that are "obvious or unimportant." A grammatical error in a comment is quite minor and doesn't affect functionality. Additionally, this looks like boilerplate template code from Rasa framework itself (the comment structure and link suggest it's from a template), so the typo may have originated from the framework's template, not from the PR author. The rules say "Do NOT comment unless there is clearly a code change required" - fixing a typo in a comment is not a code change that affects functionality. This is an unimportant, purely cosmetic issue. The typo does exist and technically the comment is correct. If we're being pedantic about code quality, even comments should be grammatically correct. However, this is template/boilerplate code and the issue is extremely minor. While the typo technically exists, the rules explicitly state not to make comments that are "obvious or unimportant." A grammatical error in a boilerplate comment that doesn't affect code functionality is clearly unimportant. The rules prioritize actionable, important feedback over pedantic corrections. This comment should be deleted. It's pointing out a minor grammatical error in a boilerplate comment that has no impact on code functionality. This violates the rule against making obvious or unimportant comments.
23. problem-solver/cxx/message-classification-module/test/test-structures/wit_concepts.scs:58
- Draft comment:
Typographical note: In the 'concept_message_with_emotional_coloring' block, the identifier [wit$sentiment] is now terminated with a single semicolon, while [rasa$sentiment] uses a double semicolon. Please verify if this discrepancy is intentional or if it should be made consistent. - Reason this comment was not posted:
Comment looked like it was already resolved.
24. problem-solver/cxx/message-classification-module/test/test-structures/wit_concepts.scs:95
- Draft comment:
Typo: There's a trailing tab/whitespace after 'rrel_season' in the nrel_entity_possible_role line. Consider removing it for consistency. - Reason this comment was not posted:
Comment was on unchanged code.
25. problem-solver/cxx/message-classification-module/test/test-structures/wit_concepts.scs:119
- Draft comment:
Typographical: There appears to be an extraneous tab character inside the curly braces in the propertynrel_entity_possible_role: { rrel_entity };;. Please remove or standardize the whitespace. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment points out a tab character issue in line 119. Looking at the diff, the newconcept_rasa_entityblock was added, which includes line 119 with=> nrel_entity_possible_role: { rrel_entity };;. However, this exact same pattern with the tab character already existed in the original code at line 113 forconcept_wit_entity. The PR author copied this pattern when creating the new entity. While the comment is technically about a line that was added, the formatting issue pre-existed and the author was just following the existing pattern in the file. According to the rules, I should not comment on things that are not clearly code changes requiring action, and this is more of a pre-existing style issue. The line in question (119) is technically new code added by this PR, so one could argue the comment is about changes. However, the same formatting exists elsewhere in the file (line 95, 113), suggesting this is an existing codebase pattern that the author followed consistently. While line 119 is technically new, the comment is about a formatting pattern that already exists throughout the file. The author simply copied the existing style. Commenting on this would be asking the author to fix pre-existing issues, not issues they introduced. This violates the principle of only commenting on actual problems introduced by the change. This comment should be deleted because it's about a formatting pattern that pre-existed in the codebase and was simply copied by the author. The same tab character appears in lines 95 and 113 which were not modified. This is not a new issue introduced by the PR.
26. problem-solver/cxx/message-classification-module/test/units/testMessageTopicClassification.cpp:3
- Draft comment:
Typographical error detected: 'WitAiCkientMock.hpp' appears to contain a typo in 'Ckient'. Perhaps it should be 'WitAiClientMock.hpp'? - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_zpp57uX92tip38BA
You can customize 
|
|
||
| void RasaMessageTopicClassificationAgent::initFields() | ||
| { | ||
| std::unique_ptr<ClientInterface> client = std::make_unique<RasaClient>(); |
There was a problem hiding this comment.
The local variable client is created but never used. Remove it to avoid confusion.
Suggested change
| std::unique_ptr<ClientInterface> client = std::make_unique<RasaClient>(); |
| curl_easy_setopt(curl, CURLOPT_POSTFIELDS, jsonData.c_str()); | ||
|
|
||
| struct curl_slist* headers = NULL; | ||
| headers = curl_slist_append(headers, "Content-Type: application/json; charset=UTF-8"); |
There was a problem hiding this comment.
Memory leak risk: After appending header(s) with curl_slist_append, free the list using curl_slist_free_all(headers).
|
|
||
| if (res != CURLE_OK) { | ||
| std::cerr << "curl_easy_perform() failed: " << curl_easy_strerror(res) << std::endl; | ||
| return ""; |
There was a problem hiding this comment.
Error handling: In getResponse(), if curl_easy_perform fails, returning an empty string as JSON may lead to JSON parse errors. Consider handling this case more explicitly.
|
|
||
| **Wit.ai features** | ||
|
|
||
| Unlike other available message classifier(Rasa) With.ai has the ability to determine the message trait. However, a significant disadvantage of using it is its dependence on an Internet connection. Also Wit.ai it has a pre-created interface for training an existing classifier. |
There was a problem hiding this comment.
Typographical error: 'With.ai' should be corrected to 'Wit.ai' for consistency.
Suggested change
| Unlike other available message classifier(Rasa) With.ai has the ability to determine the message trait. However, a significant disadvantage of using it is its dependence on an Internet connection. Also Wit.ai it has a pre-created interface for training an existing classifier. | |
| Unlike other available message classifier(Rasa) Wit.ai has the ability to determine the message trait. However, a significant disadvantage of using it is its dependence on an Internet connection. Also Wit.ai it has a pre-created interface for training an existing classifier. |
|
|
||
| ScAddrVector RasaMessageTopicClassifier::getMessageIntentClass(ScAddr const & messageAddr, json const & rasaResponse) | ||
| { | ||
| ScAddrVector messageIntentCLassElements; |
There was a problem hiding this comment.
Typographical inconsistency: The variable name messageIntentCLassElements (and similar occurrences like messageIntentCLassEdge and possibleMessageCLass) has an unexpected capital 'L' in 'CLass'. It might be clearer if renamed to messageIntentClassElements for consistency.
| static size_t writeCallback(void* contents, size_t size, size_t nmemb, std::string* userp); | ||
| }; | ||
|
|
||
| } // namespace MessageClassificationModule |
There was a problem hiding this comment.
Typographical inconsistency: The closing comment for the namespace reads // namespace MessageClassificationModule, but the namespace declared at line 13 is namespace messageClassificationModule. Please update the closing comment to match the declared namespace.
Suggested change
| } // namespace MessageClassificationModule | |
| } // namespace messageClassificationModule |
|
|
||
| class RasaMessageClassificationAliasConstants | ||
| { | ||
| public:; |
There was a problem hiding this comment.
Typographical error: In the class RasaMessageClassificationAliasConstants, the access specifier is written as public:;. Remove the semicolon to have just public:.
Suggested change
| public:; | |
| public: |
| - Какой срок сдачи [первой лабораторной работы](rrel_entity)? | ||
| - Когда защита [второй лр](rrel_entity)? | ||
| - Когда можно сдать [третью лабу](rrel_entity)? | ||
| - Когда нужно сдавать [лабораторную рработу №4](rrel_entity)? |
There was a problem hiding this comment.
Typo: лабораторную рработу №4 contains an extra 'р' and should be corrected to лабораторную работу №4.
Suggested change
| - Когда нужно сдавать [лабораторную рработу №4](rrel_entity)? | |
| - Когда нужно сдавать [лабораторную работу №4](rrel_entity)? |
| - message_about_subdividing | ||
| - message_about_weather | ||
| - color_message | ||
| - unknowm_intent |
There was a problem hiding this comment.
Typo in intent name unknowm_intent. Consider changing it to unknown_intent for clarity and consistency.
| [rrel_entity];; | ||
| [rrel_entity]; | ||
| => nrel_rasa_idtf: | ||
| [rrel_entity] |
There was a problem hiding this comment.
Typographical: The property => nrel_rasa_idtf: is missing a terminating semicolon after [rrel_entity]. Please add the semicolon for consistency.
Suggested change
| [rrel_entity] | |
| [rrel_entity]; |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Complete version of Rasa message topic classification module launch via Docker
Important
Integrates Rasa message topic classification with Docker support and updates interfaces, constants, and tests for seamless integration.
RasaMessageTopicClassificationAgentinagent.rasa_classifier_modelwithDockerfile.server,Dockerfile.test, andDockerfile.train.docker-compose.ymlto include Rasa services.RasaClientimplementingClientInterfacefor Rasa API communication.WitAiClientto implementClientInterface.RasaMessageClassificationConstantsfor Rasa-specific constants.MessageClassificationHelperfor utility functions.config.yml,domain.yml,nlu.yml,rules.yml,stories.yml.replacements.ymlfor entity replacements in Rasa.tests/test_stories.ymlfor Rasa model validation.ClientInterfacefor both Rasa and Wit.ai.This description was created by
for c26730d. You can customize this summary. It will automatically update as commits are pushed.