{"id":"5deb8b7a-80ec-4fd7-a9f9-1b9adce06acd","arxiv_id":"2412.17373","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"Route search counts from an expressway website, combined with traffic sensor data, improved next-day and next-week highway speed forecasts in tests on Japanese expressways.","lead":"This paper tests whether the routes people search online before a trip can help forecast highway traffic speed a day or a week ahead. The authors report that adding search counts to traffic sensor data lowered prediction error on Japanese expressway data, though the evaluation lacks baseline comparisons.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Search-feature improvement is unverified: the ablation never tests traffic-only or traffic+time baselines, reports single-seed MAEs with no uncertainty, and tunes input size/interval on the test set.","rationale":"The paper has a real data asset (NEXCO route-search logs), and the descriptive analyses in Figs. 3-6 provide a reasonable motivation for using search records. But the central claim is empirical: adding search-record features improves long-term speed prediction relative to traffic data alone. The experiments as reported cannot establish this. The ablation design is incomplete because it removes one feature at a time from the full set rather than comparing against a traffic-only or traffic+time baseline, so the specific improvement claimed in the abstract and introduction is never directly measured. The observed differences in the one-week-ahead table are small enough to be within seed-to-seed variation for LSTM training, yet only one seed is used. Table VII's comparison of input sizes and intervals on the test set invalidates the headline MAE as an unbiased estimate. Individually these are weaknesses; together they are load-bearing because the paper's only quantitative evidence for the claimed enhancement is these MAE tables. The reader's identified weakest assumption, the fixed 80 km/h preprocessing speed, is secondary: even if corrected, the evaluation gap would remain. I therefore agree with the reader's REJECT verdict, though my load-bearing concern is the evaluation design rather than the preprocessing assumption.","tokens_in":9384,"tokens_out":7731,"duration_ms":78745,"concrete_test":"Re-run the E4 and E17 experiments with the same model, normalization, and original seed plus four additional random seeds, using feature sets: (a) traffic+time only, (b) traffic+time+time-specified search, (c) traffic+time+non-time-specified search, and (d) all four features. Select input size and day interval on the validation split, not on the test set, and report mean +/- std MAE for each feature set. If the all-features MAE is not below traffic+time by more than one standard deviation on both roads, the claimed search-record benefit does not hold.","verdict_should_be":"REJECT","load_bearing_attack":"The load-bearing condition for the paper's claim is that route-search counts contribute signal beyond traffic history. That condition is not tested. In the ablation (Tables III-IV), every row except the full-feature row omits exactly one feature; no row contains only X_traffic or X_traffic + X_time. The comparison 'traffic data without search records' that the claim requires is therefore absent. The reported benefits are also small relative to plausible training noise: in Table IV, full features give MAE 2.454 versus 2.492 without non-time-specified searches and 2.510 without time-specified searches, differences of only 0.038-0.056 km/h, and every number is a single run with the fixed seed (Section VI.A). Table VII then selects input size and day interval by comparing test MAEs ('The goal was to determine the best combination of these parameters'), so the headline 3.354 is an optimistically selected test statistic. Under these conditions, the full-feature advantage could be seed noise, capacity effects, or test-set overfitting rather than search-record signal.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes FRTP, a CNN+LSTM architecture that fuses three input groups—traffic counter data, time-specified route-search records, and non-time-specified route-search records—for long-term expressway speed prediction on NEXCO East roads. The claimed contributions are a 'federation' design that accepts heterogeneous features with different time granularities, and empirical evidence that online route-search logs improve next-day and same-weekday-next-week predictions. Experiments include an ablation on road E14, a larger fine-grained evaluation on roads E4 and E17, and a comparison of input sizes/day intervals. The best reported result is MAE 3.354 km/h for E4 next-day prediction with one day of input.","tokens_in":9645,"tokens_out":6388,"duration_ms":60623,"significance":"The proprietary NEXCO East route-search data is a genuinely novel asset, and the problem of predicting traffic several days ahead is practically important. If the incremental value of search records over traffic-only inputs were demonstrated rigorously, the paper would be a useful empirical contribution. The architecture's ability to consume features of different lengths and granularities is also attractive. However, the present evaluation does not yet establish the central claim: the ablation lacks a traffic-only baseline, results are single-seed point estimates, hyperparameters are selected on the test set, and no existing predictor is used for comparison. The significance therefore depends on completing the evaluation rather than on the current evidence.","major_comments":[{"comment":"The central claim that incorporating both types of search records significantly improves traffic prediction is not supported by the reported ablation. Every row in Tables III and IV removes exactly one feature from the full feature set, and no experiment uses only X_traffic or X_traffic plus X_time. The comparison that the paper's abstract and conclusion require—using traffic data without search records—is therefore absent. Please add the missing ablation rows (X_traffic only, X_traffic+X_time, and each search feature added separately) and report them alongside the full model.","section":"Section VI.B, Tables III-IV"},{"comment":"The hyperparameter evaluation is performed directly on test MAE: the text states that 'the goal was to determine the best combination of these parameters,' and Table VII reports the selected configurations. This makes the headline value of 3.354 km/h an optimistically chosen test statistic. Use the held-out validation split (112 days, Table V) for configuration selection, and report MAE for all combinations in Table VII rather than only the best ones.","section":"Section VI.A and Table VII"},{"comment":"No persistence, statistical, or existing deep-learning baselines are reported. The claims of 'best results' and 'significantly improve' need at least a seasonal-naive/weekly persistence baseline, an ARIMA-like model, and a traffic-only deep model (e.g., LSTM or STGNN) trained on the same data. Without such comparisons, the absolute MAEs of 2.4–3.9 km/h cannot be interpreted.","section":"Section VI.A"},{"comment":"All experiments use a single fixed random seed (1100) and report one MAE per configuration. The ablation differences in Table IV are 0.038–0.056 km/h, which may be within run-to-run variation for a CNN+LSTM. Report mean and standard deviation over several seeds, and include significance tests where appropriate.","section":"Section VI.A"},{"comment":"The assignment of time-specified search records to road segments assumes a uniform average speed of 80 km/h for all segments and times. Because the target variable is speed, misalignment under congestion or speed-limit variation could systematically distort the search-count features and inflate or attenuate their correlation with future traffic. Please justify this assumption for E4/E14/E17 or provide a sensitivity analysis with speeds from the traffic counter data.","section":"Section IV.B, step 2"}],"minor_comments":[{"comment":"The proposal is called FLTP in the last paragraph of Section II.C but the paper title and abstract use FRTP; harmonize the acronym.","section":"Section II.C"},{"comment":"The text states that 'the MAE value of using merely specified time ... dropped to 2.790,' but no such value appears in Table III (which lists 2.415, 2.586, 2.979, and 3.040); correct the text or the table.","section":"Section VI.B"},{"comment":"Equation (1) uses X_t for historical traffic features while P is defined as the traffic time series; clarify the relationship between P and X_t.","section":"Section III.A"},{"comment":"The summation uses \\hat y and y without indices; write \\hat y_i and y_i for consistency with the definition of n.","section":"Equation (2)"},{"comment":"The formatting under 'Items' is inconsistent, with 'Items Values' repeated and rows split across lines; align the entries for readability.","section":"Tables II and V"},{"comment":"The text says the convolution operates on feature dimensions, but it is not clear what the input tensor dimensions are or why this captures spatial dependencies; add a formal tensor-shape description.","section":"Section V.A and Fig. 7"},{"comment":"The meaning of 'day interval 6' is ambiguous; specify whether it is measured from the end of the input window or from its start, because the phrase 'same weekday of the next week' depends on that convention.","section":"Section VI.C and Table VII"}],"recommendation":"major_revision","confidential_remarks":"The proprietary NEXCO East data set is a genuine asset, but the evaluation as written cannot support the paper's central claims. I see the main issues as fixable within the scope of an empirical revision: add the missing traffic-only ablations, add standard baselines, move hyperparameter selection to the validation split, and report multiple-seed uncertainty. The paper should also be checked for internal inconsistencies between the text and tables, such as the 2.790 value in Section VI.B."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the data is the thing. A proprietary set of route search logs from NEXCO East, split into time-specified and non-time-specified, is genuinely valuable for long-term traffic prediction. The preprocessing (shortest-path assignment, resampling) is reasonable, and the CNN+LSTM fusion architecture with max-pooling is a clean way to handle heterogeneous time granularities. The descriptive correlation analysis is worth a look.\n\nBut the central claim—that adding search records improves prediction over traffic data alone—is not actually tested. The ablation (Tables III and IV) removes one feature at a time, but no row feeds the model only traffic data. So we never see the baseline the whole paper depends on. The improvements over removing a single search-type are small: 2.454 vs 2.492/2.510 for the next-week task. With a single seed and no uncertainty, those gaps could easily be noise. On top of that, Table VII selects input size and day interval by comparing test-set MAEs, making the headline 3.354 an optimistically chosen test statistic. The 80 km/h speed assumption and the 1/3/7/10-day resampling windows are unvalidated, though the correlation plots make me think these are secondary.\n\nThe paper also lacks any external baselines—no persistence, no ARIMA, no standard deep model. So even if the ablation were properly designed, we wouldn't know whether this architecture is competitive. The authors are not sloppy in their writing; the method is coherent, and the problem is well defined. But the evaluation simply doesn't support the conclusion as written.\n\nWho is this for? ITS researchers who work with unusual data sources and need a template for fusing heterogeneous temporal features. They'll get ideas from the architecture and the data-processing pipeline. But anyone citing this for the result that search logs improve long-term forecasting would be over-reading.\n\nMy recommendation: send it to peer review, but with the expectation of major revision. The dataset is rare and the architecture is reusable, so it deserves referee time. The authors need to add a traffic-only baseline, external baselines, multiple seeds, and move hyperparameter selection off the test set. That's a doable revision, not a fundamental flaw.","headline":"A rare and valuable dataset, but the paper never actually tests whether search logs beat traffic data alone.","tokens_in":10125,"tokens_out":2907,"would_cite":false,"duration_ms":27866,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Search logs take next-day expressway speed error to 3.35 km/h.","keywords":["traffic prediction","long-term forecasting","route search records","online search logs","convolutional LSTM","data federation","expressway traffic"],"falsifier":"On road segments whose observed average speed is well below 80 km/h, retrain the model with and without time-specified search counts and compare the ablation gap; if the gap disappears or reverses on those segments, the 80 km/h alignment assumption is the reason search features helped. A second check would replace the fixed 1/3/7/10-day lookback windows with other lags and see whether the claimed improvement persists.","tokens_in":9190,"feed_emoji":"🛣","tokens_out":5499,"duration_ms":50007,"temperature":0.7,"pith_summary":"Long-term traffic speed prediction, forecasting tomorrow or the same weekday next week, is harder than short-term prediction because the connection between past road conditions and far-future outcomes is weak. This paper claims that online route-search records, which capture drivers' plans before they enter the road network, carry predictive signal that helps close that gap, and that fusing them with traffic data improves accuracy. The authors test a convolutional-LSTM model that ingests raw search and traffic features at different time granularities, reporting that using all features together beats any subset, with a best next-day mean absolute error of 3.354 km/h on road E4. If the claim holds, traffic operators and travelers gain a practical way to anticipate congestion several days in advance.","feed_headline":"Search logs take next-day speed error to 3.35 km/h","feed_subtitle":"Fusing route-search clicks with traffic data beats traffic data alone for speeds a day and a week ahead on Japanese expressways.","key_machinery":"The load-bearing mechanism is a convolutional-LSTM model with a data-federation stage folded into the learning process. A convolution layer operates on the feature dimension, compressing heterogeneous inputs (traffic counters, time-specified search counts, non-time-specified search counts, and road features) into a fixed number of output features; a max-pooling layer with ratio R aligns input and output time granularities; and an LSTM captures long temporal dependencies. Before feeding the model, raw search records are converted to counts: shortest routes between interchange pairs are computed with Dijkstra's method, time-specified searches are assigned to road segments assuming an average travel speed of 80 km/h, and non-time-specified searches are resampled at 1, 3, 7, and 10-day offsets. This preprocessing-plus-network design is what lets the model handle features with different time lengths and granularities without manual downsampling.","core_discovery":"The paper's central claim is that route-search logs are useful for long-term traffic prediction, and that a federated architecture learning directly from raw heterogeneous features can exploit them. On its own terms: time-specified searches, where the user gives a departure or arrival time, show a strong correlation with future traffic volume, while non-time-specified searches, where no datetime is given, add complementary signal when resampled at 1, 3, 7, and 10 days before the target. An ablation on road E14 shows the full feature set yields the lowest MAE, at 2.415 for next-day prediction, and on the larger E4/E17 evaluation one day of input predicting the next day reaches MAE of 3.354 and 3.596 km/h respectively. The paper concludes that incorporating both types of search records significantly improves long-term traffic prediction.","pith_inferences":["If the flat 80 km/h assignment speed were replaced by segment-specific or time-of-day speeds, the alignment of time-specified searches to road segments could shift; the paper does not test this, so the size of the current gain that depends on that approximation is unknown.","The same federation pattern could transfer to other pre-trip digital traces, such as transit-app trip planning or ride-hailing search queries, whenever a query encodes travel intent ahead of departure.","The 1/3/7/10-day lookback windows for non-time-specified searches are a fixed grid; learning these offsets with an attention mechanism or a flexible lag module is a testable extension that the paper leaves open.","The evaluation covers two expressway corridors in Japan, so the claim that search logs improve long-term prediction has not yet been shown for urban surface streets or other countries with different search and driving cultures."],"forward_implications":["Using all four feature groups (traffic, time, time-specified search, and non-time-specified search) beats every subset in the ablation, with full-feature MAE of 2.415 versus 2.586 for next-day E14 prediction with only non-time-specified search added.","One day of 5-minute input with a next-day output is the best configuration tested on both large roads, reaching MAE 3.354 km/h on E4 and 3.596 km/h on E17.","Removing the time feature hurts the most, giving MAE 3.040 for next-day and 3.408 for next-week prediction on E14, so calendar context is essential alongside search data.","Search counts are higher on weekends and holidays, and the correlation analysis ties search activity to occupancy and vehicle counts, implying search logs are most informative when demand is unusual.","The federation design is parameter-light: only road count, input-time length, input-to-output ratio, and feature counts must be set, making it straightforward to retarget to other feature types and time scales."],"supporting_citations":[{"why":"Earlier work on traffic congestion prediction using toll and route search log data from the same source, which this paper directly extends.","marker":"[26]"},{"why":"Prior demonstration that online search log data can improve long-term traffic prediction, providing the direct baseline for the paper's central claim.","marker":"[27]"},{"why":"The Drive Plaza route and toll search service from which the time-specified and non-time-specified search records are collected.","marker":"[28]"},{"why":"NEXCO East as the collaborator supplying the traffic counter data, road network data, and the evaluated roads E4, E14, and E17.","marker":"[10]"},{"why":"The LSTM architecture for traffic speed prediction that supplies the temporal-sequence component of the proposed convolutional-LSTM model.","marker":"[2]"}],"fun_headline_variants":["Search logs reduce long-term traffic forecast error","Federated architecture learns raw route searches for traffic","Time-stamped search queries boost week-ahead speed accuracy","Day-ahead error hits 2.415 km/h with search logs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that online search counts, once projected onto road segments using a flat 80 km/h travel speed and fixed 1/3/7/10-day lookback windows, represent future traffic demand accurately enough to improve prediction; if that projection misplaces the searches, the reported gains would not generalize.","fun_headline_variants_meta":{"raw":{"variants":["Search logs reduce long-term traffic forecast error","Federated architecture learns raw route searches for traffic","Time-stamped search queries boost week-ahead speed accuracy","Day-ahead error hits 2.415 km/h with search logs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000889,"raw_usage":{"total_tokens":3827,"prompt_tokens":927,"completion_tokens":2900,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":543,"completion_tokens_details":{"reasoning_tokens":2834}},"tokens_in":543,"tokens_out":2900,"duration_ms":22198,"temperature":1.0,"reasoning_tokens":2834,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T05:31:07.691618+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On road segments whose observed average speed is well below 80 km/h, retrain the model with and without time-specified search counts and compare the ablation gap; if the gap disappears or reverses on those segments, the 80 km/h alignment assumption is the reason search features helped. A second check would replace the fixed 1/3/7/10-day lookback windows with other lags and see whether the claimed improvement persists.","supporting_citations":[{"cited_title":"Traffic congestion prediction using toll and route search log data,","cited_arxiv_id":null,"evidence_quote":"Earlier work on traffic congestion prediction using toll and route search log data from the same source, which this paper directly extends."},{"cited_title":"Improving long-term traffic prediction with online search log data,","cited_arxiv_id":null,"evidence_quote":"Prior demonstration that online search log data can improve long-term traffic prediction, providing the direct baseline for the paper's central claim."},{"cited_title":"Dorapura service,","cited_arxiv_id":null,"evidence_quote":"The Drive Plaza route and toll search service from which the time-specified and non-time-specified search records are collected."},{"cited_title":"Nexco east,","cited_arxiv_id":null,"evidence_quote":"NEXCO East as the collaborator supplying the traffic counter data, road network data, and the evaluated roads E4, E14, and E17."}],"review_version":1}