새로 구현한 MATH, OCW 용 CoT solution 파싱 함수utils.llm_query_utils.extract_ans_from_cot_MATHnOCW 를 구현하고 채점해본 결과 GSM fewshot을 통해서 얻어낸 CoT 솔루션들에서 다음과 같은 변화가 관찰됨. 앞으로 이 파싱함수로 실험을 진행함.
Metric
Math
OCW
old_acc
0.247
0.099
new_acc
0.266 (+ 1.9%p)
0.195 (+ 9.6%p)
delta correct
(+ 97 / 4996)
(+26 / 272)
과정
src/utils/math_util.py: is_ocw_equiv 에 대한 의문 --> 내부적으로 파싱이 너무 많이 실패하고 있는 것은 아닌가? 꼭 그렇진 않았다
src/utils/llm_query_utils.py: extract_num_turbo 에 대한 의문: MATH, OCW 는 CoT 답변 양상이 다른데 파싱에 문제가 있진 않은가? --> 실제로 파싱에 문제가 있었다
ocw 정답을 어째서 utils.math_util.normalize_symbolic_expression 으로 정규화하지 않았는지에 대해 테스트해보았으나
이 차이는 2와 함께 테스트하면서 드러났고, is_equiv_ocw 는 원래의 implementation 을 최대한 유지하는 것이 더 바람직한 것으로 보임.
테스트 흔적들:
./src/prompt_construction-src/tests/*.py
./src/prompt_construction_src/tests/test_diff_by_parsing_cot.ipynb
TL;DR
utils.llm_query_utils.extract_ans_from_cot_MATHnOCW를 구현하고 채점해본 결과 GSM fewshot을 통해서 얻어낸 CoT 솔루션들에서 다음과 같은 변화가 관찰됨. 앞으로 이 파싱함수로 실험을 진행함.old_accnew_accdelta correct과정
is_ocw_equiv에 대한 의문 --> 내부적으로 파싱이 너무 많이 실패하고 있는 것은 아닌가? 꼭 그렇진 않았다extract_num_turbo에 대한 의문: MATH, OCW 는 CoT 답변 양상이 다른데 파싱에 문제가 있진 않은가? --> 실제로 파싱에 문제가 있었다ocw 정답을 어째서
utils.math_util.normalize_symbolic_expression으로 정규화하지 않았는지에 대해 테스트해보았으나 이 차이는 2와 함께 테스트하면서 드러났고, is_equiv_ocw 는 원래의 implementation 을 최대한 유지하는 것이 더 바람직한 것으로 보임.테스트 흔적들: ./src/prompt_construction-src/tests/*.py ./src/prompt_construction_src/tests/test_diff_by_parsing_cot.ipynb