Skip to content
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

Additional feedback #2

Open
pooyanjamshidi opened this issue Nov 19, 2024 · 0 comments
Open

Additional feedback #2

pooyanjamshidi opened this issue Nov 19, 2024 · 0 comments

Comments

@pooyanjamshidi
Copy link

Here are a few more additional feedback per your request:

Performance Measurement Tips

  1. Latency Measurement:

    • Since CRITIC operates in real-time, precise measurement of input-to-result latency is critical. Consider breaking this down into stages, such as input capture, inference time, and output generation.
    • Use benchmarking tools like timeit (Python) or custom logging to capture these metrics. Be mindful of any additional delays introduced by intermediate layers, like pre-processing or post-processing.
  2. Resource Utilization (CPU vs. GPU):

    • For CPU-based inference, ensure you’ve optimized for thread usage (e.g., using libraries like Intel MKL or OpenBLAS if applicable).
    • For memory usage, frameworks like memory_profiler (Python) or valgrind/massif (C++) can help identify bottlenecks.
  3. Correctness Evaluation:

    • To test how well CRITIC predicts the intended text, you might design test cases that include common typing errors, varied contexts (e.g., technical, casual, multilingual), and edge cases.

Key Feedback on Your Approach

  • Adaptive Use of LLMs:

    • If you remember, I mentioned this idea to you before, but not too sure whether it makes sense, Nicholas can judge it. An interesting optimization for resource usage and accuracy could involve adaptive LLM application. For example, at the beginning of typing, when there is no context, a keyboard model can provide sufficient predictions while being energy efficient. As more context becomes available, you can switch to using the LLM for more accurate corrections. This approach balances performance and efficiency effectively.
  • Keyboard and Language Modeling:

    • Your approach to integrating knowledge about how people make typos is a strength. It might also help to consider user behavior, such as typing speed and common autocorrect failures, to refine the probabilities.
  • LLM Behavior and Overcorrection Risks:

    • The risk of overcorrection or misinterpretation in technical fields is well-identified. To mitigate this, you could explore using a domain-specific fine-tuning approach with smaller datasets if feasible.
  • Visualizing Results:

    • For the presentation, consider visualizing your performance metrics with clear plots (e.g., latency distribution across sample texts or memory usage vs. input size). Comparisons with existing solutions would add further value.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant